ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@anyware-tech.com>
Subject Re: Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)
Date Thu, 17 Apr 2008 16:15:53 GMT
Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée <
>
> nicolas.lalevee@anyware-tech.com> wrote:
> > Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> > > On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <bruce@callenish.com>
> >
> > wrote:
> > > > I think you have to accept that there will be bugs. After all, would
> >
> > you
> >
> > > > halt the whole release if a minor bug was found the day before it was
> >
> > due
> >
> > > > to be published?
> > > >
> > > > But there are different categories of bugs. Some are so serious that
> >
> > you
> >
> > > > don't want to roll a release with it no matter what. This category
> >
> > really
> >
> > > > should result in pulling a release the day before publishing. Then
> >
> > there
> >
> > > > is a descending scale after that.
> > > >
> > > > My suggestion would be to use the Priority field for this purpose.
> >
> > Here
> >
> > > > is how I use the Jira priorities:
> > > >  - Anything labeled "Blocker" should be fixed ASAP. It might be
> >
> > impacting
> >
> > > > other developers working from the tip or perhaps breaking Gump.
> > > >  - "Critical" is for anything that has to be fixed before a release
> >
> > can
> >
> > > > go out.
> > > >  - "Major" issues should be targeted for fixing for a release and
> >
> > their
> >
> > > > number kept as low as possible, but if any ended up in a release you
> > > > wouldn't lose sleep over it.
> > > >  - "Minor" issues are the "nice-to-haves".
> > > >  - "Trivial" issues are ones that someone has complained about but
> > > > the developers don't see that fixing them would significantly improve
> > > > the product.
> > > >
> > > > If you have some sort of standard like that to go by, I think you can
> > > > fairly rapidly differentiate the bugs and then define a release as:
> > > > No Blockers or Criticals, and as few Majors as is practical to
> > > > accomplish within the time span available. The number of Minors and
> > > > Trivials are ignored.
> > >
> > > That sounds like a good practice. What do others think? How do we
> >
> > proceed
> >
> > > to classify the open bugs?
> >
> > I am in favor of a such classification too. About the process to classify
> > them, I would say that it would be the same process as fixing issues. A
> > committer get interested to an issue, try to found out to what's behind,
> > and
> > then decides its priority. And the other committers check via the
> > notifications@ant list.
>
> But how do we know that the issue priority has been reviewed, especially if
> it doesn't change?

ha, good point :)

So I guess the review have to be done by some volonteers, the list of 
remaining issues being shared between them.
I think I can get some time at the end of next week to help.

Nicolas

>
> Xavier
>
> > Nicolas
> >
> > > Xavier
> > >
> > > > Xavier Hanin wrote:
> > > > > More than one month ago we agreed to focus on bug fixing for 2.0
> >
> > final
> >
> > > > > (see
> > > > > my original mail below).
> > > > > At that time we had about 80+ issues targeted at 2.0.
> > > > > Since then it seems we have fixed 57 issues:
> >
> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> >
> > > > >d=12310580&fixfor=12313012
> > > > >
> > > > > But we still have 64 issues to fix, which shows that new issues
> >
> > comes
> >
> > > > > up (or
> > > > > some where retargeted or created to detail issues being fixed).
> > > > >
> > > > > This leads me to one question: is our objective to fix all open
> > > > > bugs for 2.0
> > > > > too ambitious?
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > > > For additional commands, e-mail: dev-help@ant.apache.org
> >
> > --
> > Nicolas LALEVÉE
> > ANYWARE TECHNOLOGIES
> > Tel : +33 (0)5 61 00 52 90
> > Fax : +33 (0)5 61 00 51 46
> > http://www.anyware-tech.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message