You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@apache.org> on 2007/06/29 02:36:16 UTC
Re: Division of Cocoon's JIRA project
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/
Re: Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 13.07.2007 15:46, Grzegorz Kossakowski wrote:
>
>> I don't know the process in detail but the most important work is
>> related to the fact that components are not migrated and have to be
>> recreated manually. Of course, we won't need all of them because many
>> components will be replaced by own project.
>>
>> Other things that come to mind is updating our poms, writing JIRA
>> welcome page: https://issues.apache.org/jira/browse/COCOON, creating
>> versions and so on.
>>
>> Lots of tedious work. I'd be happy to take advantage of your help!
>> What are your plans? I'd be able to start on Monday, I guess.
>
> I can do the Jira things. Haven't worked with Maven yet, so that's
> probably not my part. The first steps is to be done by infra anyway,
> isn't it?
Yes, I've asked them for opinions on improved (COCOON prefixes added) proposal:. If they are fine with it I'll call a vote and we'll talk
about sharing the effort.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2007 15:46, Grzegorz Kossakowski wrote:
> I don't know the process in detail but the most important work is
> related to the fact that components are not migrated and have to be
> recreated manually. Of course, we won't need all of them because many
> components will be replaced by own project.
>
> Other things that come to mind is updating our poms, writing JIRA
> welcome page: https://issues.apache.org/jira/browse/COCOON, creating
> versions and so on.
>
> Lots of tedious work. I'd be happy to take advantage of your help! What
> are your plans? I'd be able to start on Monday, I guess.
I can do the Jira things. Haven't worked with Maven yet, so that's
probably not my part. The first steps is to be done by infra anyway,
isn't it?
Joerg
Re: Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
>
> What actual work needs to be done with the division process? Maybe I can jump in.
I don't know the process in detail but the most important work is related to the fact that components are not migrated and have to be
recreated manually. Of course, we won't need all of them because many components will be replaced by own project.
Other things that come to mind is updating our poms, writing JIRA welcome page: https://issues.apache.org/jira/browse/COCOON, creating
versions and so on.
Lots of tedious work. I'd be happy to take advantage of your help! What are your plans? I'd be able to start on Monday, I guess.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
> > No, as far as I know we can't do it without them anyway. Maybe just
> > re-ask with the "offer" to use the COCOON prefix?
>
> I could do that but I have no free time to handle division process now. I want
> to make some progress on my GSoC work.
>
> Let it be that I'll try to push things forward with COCOON prefix but I'll not
> set any schedules for now.
What actual work needs to be done with the division process? Maybe I can jump in.
Joerg
Re: Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 11.07.2007 01:15, Ralph Goers wrote:
>
>> But neither do you see a positive reaction.
>>
>> I believe Maven structures their Jira as has been requested, but it
>> isn't hosted at Apache.
>
> There are more projects set up like this like Avalon stuff and
> especially (no longer Jakarta) Commons.
Yep.
> No, as far as I know we can't do it without them anyway. Maybe just
> re-ask with the "offer" to use the COCOON prefix?
I could do that but I have no free time to handle division process now. I want to make some progress on my GSoC work.
Let it be that I'll try to push things forward with COCOON prefix but I'll not set any schedules for now.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 11.07.2007 01:15, Ralph Goers wrote:
>> So I can't see a negative reaction from infra.
>>
> But neither do you see a positive reaction.
>
> I believe Maven structures their Jira as has been requested, but it
> isn't hosted at Apache.
There are more projects set up like this like Avalon stuff and
especially (no longer Jakarta) Commons.
> The real question for me is, do we need
> explicit permission to do this or do we do it unless someone says no. I
> get the impression that the second alternative is your preferred approach.
No, as far as I know we can't do it without them anyway. Maybe just
re-ask with the "offer" to use the COCOON prefix?
Joerg
Re: Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke wrote:
> On 10.07.2007 23:08, Ralph Goers wrote:
>
>> We also got this response:
>>
>> Jeff Turner pisze:
>>
>> 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).
>
> That was exactly what I meant: Jeff put our need into question but
> Grek explained our needs in detail [1]. The rest of the thread - as
> far as it was on this list - was only about the prefix. So I can't see
> a negative reaction from infra.
>
But neither do you see a positive reaction. The rest of the thread?
Basically, I think those were the only two replies.
I believe Maven structures their Jira as has been requested, but it
isn't hosted at Apache. The real question for me is, do we need
explicit permission to do this or do we do it unless someone says no. I
get the impression that the second alternative is your preferred approach.
I really have no opinion one way or another on whether to divide up the
modules, but I would have liked a bit more of an answer.
Ralph
Re: Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.07.2007 23:08, Ralph Goers wrote:
> We also got this response:
>
> Jeff Turner pisze:
>
> 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).
That was exactly what I meant: Jeff put our need into question but Grek
explained our needs in detail [1]. The rest of the thread - as far as it
was on this list - was only about the prefix. So I can't see a negative
reaction from infra.
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=118311200008477&w=4
Re: Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
We also got this response:
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).
Joerg Heinicke wrote:
> On 10.07.2007 04:57, Grzegorz Kossakowski wrote:
>
>> Even more, INFRA people are little unwilling to fulfil what we ask
>> for so I think it's crucial to have a strong support from our community.
>
> Can they neglect or deny our project's needs? It's ok they put them
> into question, but from the points you made it should be rather clear
> we need the dividing into multiple projects. They made a point with
> the prefix which we can address with the COCOON prefix. So should
> there really still be any problem?
>
> Joerg
Re: Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.07.2007 04:57, Grzegorz Kossakowski wrote:
> Even more, INFRA people are little unwilling to fulfil what we ask for
> so I think it's crucial to have a strong support from our community.
Can they neglect or deny our project's needs? It's ok they put them into
question, but from the points you made it should be rather clear we need
the dividing into multiple projects. They made a point with the prefix
which we can address with the COCOON prefix. So should there really
still be any problem?
Joerg
Re: Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
>> As a disinterested observer, I'd note that 'C' isn't enough to
>> differentiate between Cocoon & the other existing Apache/Incubator
>> projects of Cayenne or CXF, let alone any future ones, so I'd not have
>> thought so, personally...
>
> What's the outcome? Do we go with COCOON prefix?
Joerg, thanks for keeping interest in this affair. I must admit that I neglected the thread because I felt it was not going to end up
successfully. Given the fact that is quite important thing for our community to divide JIRA project the feedback was rather small.
Even more, INFRA people are little unwilling to fulfil what we ask for so I think it's crucial to have a strong support from our community.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
What outcome? The response below was pretty much the only reply.
Joerg Heinicke wrote:
> On 29.06.2007 07:09, Gwyn Evans wrote:
>
>>>>> 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.
>>
>>> Some keys will become really long, isn't 'C' enough as a prefix?
>>
>> As a disinterested observer, I'd note that 'C' isn't enough to
>> differentiate between Cocoon & the other existing Apache/Incubator
>> projects of Cayenne or CXF, let alone any future ones, so I'd not have
>> thought so, personally...
>
> What's the outcome? Do we go with COCOON prefix?
>
> Joerg
Re: Division of Cocoon's JIRA project
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.06.2007 07:09, Gwyn Evans wrote:
>>>> 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.
>
>> Some keys will become really long, isn't 'C' enough as a prefix?
>
> As a disinterested observer, I'd note that 'C' isn't enough to
> differentiate between Cocoon & the other existing Apache/Incubator
> projects of Cayenne or CXF, let alone any future ones, so I'd not have
> thought so, personally...
What's the outcome? Do we go with COCOON prefix?
Joerg
Re: Division of Cocoon's JIRA project
Posted by Gwyn Evans <gw...@gmail.com>.
On Friday, June 29, 2007, 11:12:29 AM, Grzegorz <gr...@tuffmail.com> wrote:
>>> 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?
As a disinterested observer, I'd note that 'C' isn't enough to
differentiate between Cocoon & the other existing Apache/Incubator
projects of Cayenne or CXF, let alone any future ones, so I'd not have
thought so, personally...
/Gwyn
Re: Division of Cocoon's JIRA project
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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/
Re: Division of Cocoon's JIRA project
Posted by Ralph Goers <Ra...@dslextreme.com>.
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/
>>