cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Division of Cocoon's JIRA project
Date Fri, 29 Jun 2007 03:08:50 GMT
How is maven organized? I would think that the Cocoon modules would be 
very similar to the way Maven plugins are managed. Yes - as I understand 
it, it is intended that the Cocoon modules could be versioned independently.

Ralph

Jeff Turner wrote:
> 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/
>>     

Mime
View raw message