Jeff Turner pisze:
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).
In Apache Cocoon we have concept called "block". It is a self-containing package (JAR file) which extends Cocoon functionality to almost any
extend. To not discuss details think of block as a plug-in. We have been having a Cocoon's source code divided into blocks for years. Only
now, thanks to Maven we have a necessary infrastructure to release and deliver these blocks independently.
Our main motivation for having separate projects is that we really need
independent versioning.
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?
Yes, and yes.
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?
I think, yes. Every block has it's own Java package and focuses clearly on some functionality so usually users will now to which project the
problem/bug belongs.
Have a look at our (unpublished yet) docs:
http://cocoon.zones.apache.org/dev-docs/2.2/blocks/
We already have a very clear separation of each part, only JIRA separation is
lacking now.
Apart from versioning, are there any other fields common to each
'project' that JIRA's current organization prevents you having?
Versioning is most important, the same goes for release notes etc.
2. One big project is simply too big
"too big" meaning? There are plenty of larger or comparably sized
projects in JIRA:
I'm not sure about projects mentioned below but what about componenets? We have plenty of them and I guess we would have to double the
number of them to cover all Cocoon's corners.
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).
Some keys will become really long, isn't 'C' enough as a prefix?
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).
Can't we run bulk move for each version separately? When it comes to component information it's not that important, we would have to
restructure significantly anyway.
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.
As explained earlier we are really leaning towards independent releases. There are part in Cocoon that will probably grow rapidly (servlet
service fw) and will demand lots of releases and parts that are quite stable and will be released at slower peace. Mixing such parts is not
convenient for us.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
