Ben Fowler wrote:
I would respectfully disagree with both of the substantive points in this thread(!):
But you forgot to reply to the list ;)
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
Bryce Harrington wrote:
[ snip ]
Where the project needs help right now is in closing bugs. We have our bug tracker quite well under control, but there are 258 open bugs, and it would be wonderful if we could cut that down significantly before the 0.43 release. If you can code, please check out if you can help close one or two, ...
I am sitting on three patches, waiting for a thaw so that I can commit without endangering other's activities. There was never much of a thaw after 0.42!
Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release.
Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle.
I suspect that I am missing something ...
Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over.
Ideally this should be based on the importance to the end-user rather than priority or ease of fixing. (High priority and easy to fix bugs should most certainly be fast tracked, but again, at the beginning or in the middle of a release cycle).
Other projects keep from time to time some events called "bug party", when people clean the bug/feature tracker, collaborating over IRC and closing as much as possible as DUPLICATE, WON'T FIX, INVALID, RESOLVED or prioritizing. It may have the benefit of attracting new contributors and giving non-developers a way to contribute.
What do you think about the opportunity/usefulness of such a bug party?
At 258 bugs and 448 RFEs the number may be small enough and the action not needed.
I wholeheartedly agree with these data and your suggestions, until the last line, where there is the implication that 250 open bugs is a small number. Really, we should be aiming at zero bugs, and should have 10 or fewer open ones.
I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little.
I would urge every effort to getting non-coders interested in triaging bugs and assigning priorities at all times. It is especially helpful to have end-users prioritising bugs, as bugs which do not impact the user community can be left to a future when there is more time.
I also note that many of the open bugs refer to the Windows operating system, and unless those they are easily reproducible they may never get seen by a developer unless the user community can get behind them and insist that (some of) such bugs are indeed important.
Well, it may also be the case some of those bugs can't be reproduced at all or referring to old versions of Inkscape and can be simply closed.
Finally, if we are going to have hundreds of open bugs, we should consider an even/odd policy, and do 'bug fixes only' for even numbered releases ...
That may not desirable if we have a large number of RFEs and/or features which developers are interested in. Certainly in the proprietary world, there are products which have benefitted from a period of stability in which six months of the developers time was spent on stabilisation, performance and bug fixing rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
Ben