New MyFaces JIRA structure

[Manfred Geiler <ma...@gmail.com>]

Hi all,
Sean already posted some thoughts recently. I know we should bring out
our next release first, but meanwhile we could have some thoughts
about future JIRA structure and version management.

Here is a short roundup of what we have:

MyFaces (sub-)projects on the site:
 API
 Impl
 Commons
 Tomahawk
 Sandbox
 (Tobago)

We will release the following assemblies with different release numbers:
 Core (= API + Impl)
 Commons
 Tomahawk (with or without Sandbox?)
 (Tobago)

I propose the following Jira-Projects:
 MYFACES
 MYFACES-COMMONS
 MYFACES-TOMAHAWK
 MYFACES-TOBAGO

All four would have the common Jira category "MyFaces". So they will
still be tied together.

There were some discussions regarding Commons in Jira. IMHO this is
the only solution, that is logical and does not lead to additional
confusion. Commons will have it's own release cycles - there is no
other way to solve this without having unwanted peculiarities. Some
alternatives, that where discussed recently:
* A custom field "Affected Commons Version": What about the "Fix
Version"? Where do I document it. Another custom field "Commons Fix
Version"? No, no, please.
* Request a JIRA enhancement? Not possible within a realistic time frame IMHO.

So, what is the real drawback? The only one I can think of (and was
noted in former discussions) is, that people will report Commons bugs
in MYFACES. Well, moving issues between Jira projects is no big deal
as already was said. And: The very same applies to Tomahawk issues.
Many many Tomahawk bugs will be reported in MYFACES, because there
will always be cases where it is not so clear which sub-projects is
causing the actual problem.
So, it's always the developer's job to finally put the issue into the
right category, project, component, or whatever.

Thoughts?

Manfred

Re: New MyFaces JIRA structure

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

So any comments on this latest version of the proposal?  I'd like to
get started on breaking out tomahawk.

Sean

On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > MyFaces (sub-)projects on the site:
> >  API
> >  Impl
> >  Commons
> >  Tomahawk
> >  Sandbox
> >  (Tobago)
>
> agreed.
>
> > We will release the following assemblies with different release numbers:
> >  Core (= API + Impl)
> >  Commons
>
> technically this is not an assembly.  its released as a maven pom and
> jar and its in ibiblio but we don't release as its own tarball.  i
> think we should stick with that policy.
>
> >  Tomahawk (with or without Sandbox?)
>
> right now its without sandbox and i agree with how it is now.
>
> >  (Tobago)
> >
> > I propose the following Jira-Projects:
> >  MYFACES
> >  MYFACES-COMMONS
> >  MYFACES-TOMAHAWK
> >  MYFACES-TOBAGO
>
> -1 to MYFACES in front of everything.  When refererencing bugs in the
> svn comments, emails, etc. its easier to say TOBAGO-101, etc.
>
> Jira allows us to group these all under one category.  So I propose we
> keep the existing category of MyFaces.  JIRA also has two naming
> concepts for the project.  The project name and the project key.  So
> here is my proposal in the format: subproject --> project name - KEY
>
> core --> MyFaces: Core - MYFACES
> commons --> MyFaces: Commons - MF-COMMONS
> tomahawk --> MyFaces: Tomahawk - TOMAHAWK
> tobago --> MyFaces: Tobago - TOBAGO
>
> The key is where the issue numbers are derived from.
>
> > All four would have the common Jira category "MyFaces". So they will
> > still be tied together.
> >
> > There were some discussions regarding Commons in Jira. IMHO this is
> > the only solution, that is logical and does not lead to additional
> > confusion. Commons will have it's own release cycles - there is no
> > other way to solve this without having unwanted peculiarities. Some
> > alternatives, that where discussed recently:
> > * A custom field "Affected Commons Version": What about the "Fix
> > Version"? Where do I document it. Another custom field "Commons Fix
> > Version"? No, no, please.
> > * Request a JIRA enhancement? Not possible within a realistic time frame IMHO.
> >
> > So, what is the real drawback? The only one I can think of (and was
> > noted in former discussions) is, that people will report Commons bugs
> > in MYFACES. Well, moving issues between Jira projects is no big deal
> > as already was said. And: The very same applies to Tomahawk issues.
> > Many many Tomahawk bugs will be reported in MYFACES, because there
> > will always be cases where it is not so clear which sub-projects is
> > causing the actual problem.
> > So, it's always the developer's job to finally put the issue into the
> > right category, project, component, or whatever.
>
> I can see Manfred's point about commons and I reluctantly agree.  We
> will probably come to regret not having a separate JIRA instance for
> this so lets just accept it now instead of trying a bunch of hacks
> that will probably not suffice.
>
> So I am +1 but with the changes I suggested above.  I will also hold
> off on doing anything JIRA related this weekend.  This is too big of a
> change and we need everyone's input.  Lets try for early next week
> instead.
>
> > Manfred
>
> Sean
>

Re: New MyFaces JIRA structure

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

> MyFaces (sub-)projects on the site:
>  API
>  Impl
>  Commons
>  Tomahawk
>  Sandbox
>  (Tobago)

agreed.

> We will release the following assemblies with different release numbers:
>  Core (= API + Impl)
>  Commons

technically this is not an assembly.  its released as a maven pom and
jar and its in ibiblio but we don't release as its own tarball.  i
think we should stick with that policy.

>  Tomahawk (with or without Sandbox?)

right now its without sandbox and i agree with how it is now.

>  (Tobago)
>
> I propose the following Jira-Projects:
>  MYFACES
>  MYFACES-COMMONS
>  MYFACES-TOMAHAWK
>  MYFACES-TOBAGO

-1 to MYFACES in front of everything.  When refererencing bugs in the
svn comments, emails, etc. its easier to say TOBAGO-101, etc.

Jira allows us to group these all under one category.  So I propose we
keep the existing category of MyFaces.  JIRA also has two naming
concepts for the project.  The project name and the project key.  So
here is my proposal in the format: subproject --> project name - KEY

core --> MyFaces: Core - MYFACES
commons --> MyFaces: Commons - MF-COMMONS
tomahawk --> MyFaces: Tomahawk - TOMAHAWK
tobago --> MyFaces: Tobago - TOBAGO

The key is where the issue numbers are derived from.

> All four would have the common Jira category "MyFaces". So they will
> still be tied together.
>
> There were some discussions regarding Commons in Jira. IMHO this is
> the only solution, that is logical and does not lead to additional
> confusion. Commons will have it's own release cycles - there is no
> other way to solve this without having unwanted peculiarities. Some
> alternatives, that where discussed recently:
> * A custom field "Affected Commons Version": What about the "Fix
> Version"? Where do I document it. Another custom field "Commons Fix
> Version"? No, no, please.
> * Request a JIRA enhancement? Not possible within a realistic time frame IMHO.
>
> So, what is the real drawback? The only one I can think of (and was
> noted in former discussions) is, that people will report Commons bugs
> in MYFACES. Well, moving issues between Jira projects is no big deal
> as already was said. And: The very same applies to Tomahawk issues.
> Many many Tomahawk bugs will be reported in MYFACES, because there
> will always be cases where it is not so clear which sub-projects is
> causing the actual problem.
> So, it's always the developer's job to finally put the issue into the
> right category, project, component, or whatever.

I can see Manfred's point about commons and I reluctantly agree.  We
will probably come to regret not having a separate JIRA instance for
this so lets just accept it now instead of trying a bunch of hacks
that will probably not suffice.

So I am +1 but with the changes I suggested above.  I will also hold
off on doing anything JIRA related this weekend.  This is too big of a
change and we need everyone's input.  Lets try for early next week
instead.

> Manfred

Sean