[proposal] Split Up JIRA Projects

[Sean Schofield <se...@gmail.com>]

I propose we split up some of the JIRA projects.  Right now everything
is lumped under MYFACES.  I haven't though through all the details but
I thought I would throw out a starter proposal to get the discussion
going.  I think we should try to act on this soon and then publish
more instructions on the website about how to report issues.

I propose we have the following projects: MYFACES, TOMAHAWK, TOBAGO. 
The current MYFACES instance will be just for the core.  We move all
of the tomahawk (and sandbox) stuff into the new TOMAHAWK one.  The
TOBAGO one will be all of the stuff that's in their incubator section
now.

My thinking is that we do NOT have a separate project for commons. 
Ultimately I think this will confuse the users.  We can report them in
MYFACES instead.

Also in the TOMAHAWK project we could add the actual components as
JIRA components and start reporting the bugs against the specific
components.  I think that will be helpful also.

Finally, we should start using 1.1.2-SNAPSHOT, etc. as version numbers
instead of nightly.  Then when releasing we add a 1.1.X version and
change the resolved in 1.1.X-SNAPSHOT to resolved in 1.1.X.

We'll have to clear it with INFRA (about having two extra projects)
but I don't really see the big deal.

Thoughts?

Sean

Re: [proposal] Split Up JIRA Projects

[Mike Kienenberger <mk...@gmail.com>]

I'm concerned with the impacts of this proposal.

I strongly suspect that we're going to start seeing issues filed
against MYFACES instead of the relevent subproject if you split them
out like this.

However, I don't know if there's a reasonable way to handle separate
releases in JIRA otherwise.  I know that Velocity split Velocity-tools
out into a separate jira issue, and I think it was for the same
reason.

I also wonder what the eventual impact of splitting out sub projects
for each project apache-wide are going to be, but that's probably
outside of the discussion.

Maybe Apache should request a JIRA enhancement to make this kind of
reorganization unnecessary.  Browsing through the JIRA system,
possibly it's already mitigated somewhat by the "category" property of
JIRA, and we only need to make sure that things are categorized
properly (I see that VELTOOLS and XERCESP seem to be uncategorized).  
However, it seems to be that it'd be better if JIRA supported separate
releases based on components.

Could we consider prefixing the names with MYFACES to at least keep
them all grouped together in JIRA?   MYFACES, MYFACESTOMAHAWK,
MYFACESTOBAGO, etc.

As for reporting bugs against commons, I think it'd be more
appropriate for them to go against TOMAHAWK by default.    Think of
the use cases.   If it's a commons bug that manifests itself against
the IMPL, then the user is already likely to post the bug against
MYFACES.   If it's a use case such that the user knows it's a commons
problem, the user is probably creating components using the shared
coded and using TOMAHAWK rather than IMPL as the build target.

On 2/13/06, Sean Schofield <se...@gmail.com> wrote:
> I propose we split up some of the JIRA projects.  Right now everything
> is lumped under MYFACES.  I haven't though through all the details but
> I thought I would throw out a starter proposal to get the discussion
> going.  I think we should try to act on this soon and then publish
> more instructions on the website about how to report issues.
>
> I propose we have the following projects: MYFACES, TOMAHAWK, TOBAGO.
> The current MYFACES instance will be just for the core.  We move all
> of the tomahawk (and sandbox) stuff into the new TOMAHAWK one.  The
> TOBAGO one will be all of the stuff that's in their incubator section
> now.
>
> My thinking is that we do NOT have a separate project for commons.
> Ultimately I think this will confuse the users.  We can report them in
> MYFACES instead.
>
> Also in the TOMAHAWK project we could add the actual components as
> JIRA components and start reporting the bugs against the specific
> components.  I think that will be helpful also.
>
> Finally, we should start using 1.1.2-SNAPSHOT, etc. as version numbers
> instead of nightly.  Then when releasing we add a 1.1.X version and
> change the resolved in 1.1.X-SNAPSHOT to resolved in 1.1.X.
>
> We'll have to clear it with INFRA (about having two extra projects)
> but I don't really see the big deal.
>
> Thoughts?
>
> Sean
>