Hi,
On Wed, Jun 27, 2007 at 01:14:33AM +0200, Grzegorz Kossakowski wrote:
> Hello,
> At Apache Cocoon development mailing list we are currently discussing[1]
> division of Cocoon's JIRA project. There are two reasons for a such move:
> 1. We are starting to release smaller parts more independently so we need
> different version sets
I don't think splitting the COCOON project is a good idea..
>From what I see, you've arbitrarily divided Cocoon modules into areas of
functionality ("core", "database", "forms" etc) and want a separate
project for each. From a JIRA modelling POV, the only advantage of
splitting these into separate projects is so each can have their own
versions, components and release process (release notes, etc).
Are you actually going to rev each part independently? Will you be making
public announcements like "Today Cocoon forms advanced to v1.2.3"? Will
users normally update their Cocoon Forms without also upgrading the Core?
Ie., are these actually separate modules from the _user's_ point of view,
rather than the developers'? When searching for bugs, will users think
to search across all relevant projects? Will they know what project to
file new bugs in?
Apart from versioning, are there any other fields common to each
'project' that JIRA's current organization prevents you having?
> 2. One big project is simply too big
"too big" meaning? There are plenty of larger or comparably sized
projects in JIRA:
jira_391=> select pkey, pcounter from project order by pcounter desc;
pkey | pcounter
----------+----------
HARMONY | 4300
GERONIMO | 3272
DERBY | 2882
AXIS2 | 2876
AXIS | 2677
XALANJ | 2386
COCOON | 2080
> One issue, raised[2] by Joerg Heinicke is if proposed JIRA keys should be
> somehow put into Cocoon context by e.g. prefixing them with 'C' letter.
>
> What's your opinion on this issue? Are you fine with keys originally
> proposed?
Splitting projects clutters the dashboard and project lists. At least
prefix each split project name with something meaningful ("COCOONCORE",
"COCOONFORMS" etc).
> I would also like to ask if there will be some administrator that would
> create all projects and move the issues (in the case that I would not have
> necessary rights to do it on my own). I wonder how to handle this quite
> complicated process smoothly as possible. Do you have ideas or experiences
> to share?
The only technical problem is that JIRA's bulk move will lose any version
and component information when moving between projects (that's what's
currently holding up the ADFFACES -> TUSCANY rename).
In summary, I don't think this makes sense from a JIRA modelling point of
view or a Cocoon users point of view, and it will just clutter JIRA for
everyone else. But then perhaps I'm just not understanding the
motivation. If Cocoon developers want to go ahead, my only caveat is that
project keys should be prefixed with "COCOON" to save everyone else
confusion.
--Jeff
> Thanks in advance.
>
> [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/73709
> [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73758
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
