On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée < [EMAIL PROTECTED]> wrote:
> Le jeudi 17 avril 2008, Xavier Hanin a écrit : > > On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <[EMAIL PROTECTED]> > 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 > [EMAIL PROTECTED] list. But how do we know that the issue priority has been reviewed, especially if it doesn't change? 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
