[seam-dev] Seam JIRA for Seam 3

Jordan Ganoff jganoff at gmail.com
Wed Apr 14 08:15:06 EDT 2010


Please create a JIRA project for the Seam 3 JMS Module: SEAMJMS

Thanks.

On Wed, Apr 14, 2010 at 7:07 AM, Pete Muir <pmuir at redhat.com> wrote:

>
> On 14 Apr 2010, at 12:05, Shane Bryzak wrote:
>
> > We now have the following SEAM project in JIRA:
> >
> > https://jira.jboss.org/jira/browse/SEAM
> >
> > The plan is to eventually remove the JBSEAM project,
>
> Well, we won't remove it, so much as close it to new traffic.
>
> > after all of its issues have been addressed in some way or another.  As
> Pete said, all Seam 2 issues should stay put in the JBSEAM project, and Seam
> 3 and higher issues should now go in SEAM.
> >
> > Shane
> >
> > On 14/04/10 20:02, Pete Muir wrote:
> >> People,
> >>
> >> We still need an issue tracker for tracking common Seam tasks:
> >>
> >> * Build infrastructure
> >> * Common documentation
> >> * Shared examples
> >> * Simultaneous release tasks
> >> * A dumping ground for "new-users" to put issues which they don't know
> where they belong (it's then up to us to triage them to the correct place).
> >>
> >> As we've diverged so much from Seam 2, I propose we create a new project
> in JIRA, SEAM, and keep JBSEAM for Seam 2 issues. This should reduce
> cross-over confusion between the two codebases' issues. It also has the nice
> sideeffect of allowing us to get rid of the unneeded JB prefix ;-)
> >>
> >> If anyone disagrees, speak up. Otherwise I'll ask Rodney to do this
> later today.
> >>
> >> Pete
> >>
> >> On 10 Mar 2010, at 11:57, Pete Muir wrote:
> >>
> >>
> >>> All,
> >>>
> >>> As we split Seam into modules (and as some like remoting and XML
> approach a beta release), we need to consider how JIRA should look for Seam
> 3.
> >>>
> >>> We plan to release modules independently, with a "feature-boxed"
> lifecycle, releasing modules either as features are added, or critical
> issues arrive. We also plan a "bundle release" at regular intervals, which
> takes all the modules, and provides a single stack that are tested to work
> well together.
> >>>
> >>> Keeping JIRA simple and monolithic has the advantage of being easy to
> understand and point people at. We can use components to track a module. We
> would have to prefix the version with the module name, and tracking issues
> to releases becomes pretty difficult.
> >>>
> >>> Using a JIRA project for each module allows much cleaner tracking of
> issues to releases.
> >>>
> >>> I favour the latter, but am interested in others opinions.
> >>>
> >>> Pete
> >>> _______________________________________________
> >>> seam-dev mailing list
> >>> seam-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/seam-dev
> >>>
> >>
> >> _______________________________________________
> >> seam-dev mailing list
> >> seam-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/seam-dev
> >>
> >
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>



-- 
Jordan Ganoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100414/78753bad/attachment-0001.html 


More information about the seam-dev mailing list