I know I'm late on this, but I'll throw in my +1 anyway.

-j

On Tue, 2004-07-20 at 13:47, Jason van Zyl wrote:
> On Tue, 2004-07-20 at 13:32, Carlos Sanchez wrote:
> > +1 
> > 
> > Also I noticed that there are many outdated issues, more than a year old,
> > that should be closed without losing time trying to reproduce them.
> 
> Agreed, I started making a sweep which is what lead me to propose the
> reorganization of the issues. I'll do a little spring cleaning while I
> move the issues.
> 
> > > -----Original Message-----
> > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> > > Sent: Tuesday, July 20, 2004 5:51 PM
> > > To: Maven Developers List
> > > Subject: JIRA issues pertaining to versions
> > > 
> > > Hi,
> > > 
> > > I'm not sure what the standard practice is for queuing up 
> > > issues to be resolved for a version but I think what we have 
> > > going on is not quite optimal.
> > > 
> > > When planning a release I would like to pick the issues that 
> > > can be tackled for a release and roadmapped. We have 120 
> > > issues outstanding for
> > > 1.1 and I really doubt they will all be done and doing the 
> > > version shuffle gets really annoying.
> > > 
> > > Basically I would think that everything is unscheduled until 
> > > you sit down and plan what issues you plan to resolve for a 
> > > release so that they can be easily roadmapped. There are 
> > > things for certain I want to do for maven 1.1, but there's a 
> > > ton of stuff that I'm pretty sure will get pushed back to 
> > > another version.
> > > 
> > > I like the way the XStream project is setup:
> > > 
> > > http://jira.codehaus.org/secure/BrowseProject.jspa?id=10230
> > > 
> > > The majority of issues are unscheduled and some plan is made 
> > > as to what is going to be fixed for 1.0.2 and 1.1. They list 
> > > things that are really planned for that version whereas we 
> > > have a massive jumble listed under 1.1. Does this make it 
> > > very hard to have a sensible roadmap?
> > > 
> > > So I would like to propose that we move the 1.1. jumble of 
> > > issues to unscheduled and start selectively applying versions 
> > > when someone is actually going to do the work to resolve the 
> > > issue or we're going to end up with a version shuffle. Right 
> > > now it is pretty difficult to get a clear view of the issues 
> > > that are really going to be resolved for 1.1.
> > > 
> > > 
> > > --
> > > jvz.
> > > 
> > > Jason van Zyl
> > > [EMAIL PROTECTED]
> > > http://maven.apache.org
> > > 
> > > happiness is like a butterfly: the more you chase it, the 
> > > more it will elude you, but if you turn your attention to 
> > > other things, it will come and sit softly on your shoulder ...
> > > 
> > >  -- Thoreau 
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED] For 
> > > additional commands, e-mail: [EMAIL PROTECTED]
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
-- 
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to