On Fri, Sep 16, 2005 at 02:41:35PM +0300, Nicu Buculei wrote:
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
Bryce Harrington wrote:
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!
Due to the summer of code students, it was our intent to push out 0.43 pretty quickly. However, I think there might have been some confusion in that between the 0.42.0 release and 0.42.2, CVS HEAD was open for 0.43 work for about a month.
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 ...
What you describe is pretty much how we work. I think you might have come in at the middle, and the 0.42.2 patch release might have been confusing.
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).
Yes, we go through two bug fixing phases; the first we set a point goal and accept any bug fixes, and discourage feature work, in order to allow the codebase to stabilize. The second is a hard freeze, where identify a set of up to a dozen 'must fix' bugs and limit CVS commit access to two 'release wardens'. During that phase all work must be sent to them as patches for review and integration, and they provide a tight final quality control before we go ahead and branch the release. This ensures we as a project place maximum focus on QC ahead of a release.
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'd love to see us have zero bugs, but of course there's a balance between being perfect and releasing regularly. ;-)
Where we've been drawing the line is achieving zero bugs that lead to crashes or data corruption. Cosmetic bugs, usability issues, and incompatibilities are also important, but getting all those solved is more of a long term objective.
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.
Yup, we do this quite regularly, and we've gotten quite a few good volunteers to help with this prioritization work. Of course, we could always use a few more! Both bugs and RFEs need some prioritization effort right now.
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.
I think you'll find as you get involved with the bug efforts that we actually do get remarkably good participation from the user community in replicating bug reports and in validating fixes. This has been especially true for some of the bugs related to localization. I think we actually have a fair number of Win32 devs, and we're even starting to see some OSX-based devs, however I think we could really use more of each.
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 ...
Actually, we started doing this semi-officially with the 0.42 release. 0.43 is being considered a bit more development-oriented, and 0.44 will be considered a more aggressive bug-killing release. If you're strongly interested in seeing us get our bug count down closer to zero, I'd definitely encourage you to jump in on the 0.44 release. I'd love to see us cut our current open bug count in half at least (we've done it before, I think we could do it again.)
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 ...
Of course, keep in mind that as an open source project, the personal desires of the participants play a very large role in determining what the project as a whole focuses on. A commercial organization can force its developers to work on whatever it wants, but with Inkscape since we're volunteer driven and since we put a high value on keeping things fun, the project doesn't work that way.
I think we actually get better productivity and make most efficient use of our resources by letting people work on what interests them rather than trying to drive it top-down. I think enough of us get top-down driving from work. ;-) I think when the developer has the freedom to work on what they feel the urge to work on, they enjoy the work more, and spend more of their time on it. It usually turns out that the bugs still get fixed, the features still get implemented, just maybe not quite in the order you'd have planned for. Looking back over our roadmap for the past couple years, I see that the stuff we wanted to achieve has been getting done quite rapidly, even though (or because?) we don't give out assignments or require weekly status reports or whatnot.
Ultimately, in my view, while we love our users, their input regarding prioritization of bugs and features is probably less worthwhile than just having them interact directly with the developers and let the developers' personal judgement be what sets the priorities. Ideally, if a user has a need that is a high priority, the best solution is to encourage her to contribute towards that thing - even if she doesn't code, there's still plenty of ways she can help, through testing, bug analysis, creation of mockups for new features, writing documentation, and so forth. It often turns out that once you put in some time yourself towards some issue, it builds momentum as others take interest and chip in where they see they can help, and before you know it the bug's fixed or the feature's implemented, and everyone's had a bunch of fun. :-)
Bryce