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 08:38:44 GMT
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.

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


Mime
View raw message