On Thu, Jan 24, 2008 at 01:34:55AM +0100, Maximilian Albert wrote:
J.B.C.Engelen@...1578... wrote:
The rate of bug fixing has drastically slowed down compared with a month ago, and it's a bit of a concern. Thoughts?
I think there are many bugs that are not reported, but are critical and are being fixed.
I agree with Johan - a lot of bugs that are not in the tracker are still critical (at least to a certain extent) and are constantly being fixed (although indeed it seems that the rate has slowed down a bit, but this is probably due to vacations being over and such).
Then let me rephrase - The rate of bugs being closed as fixed in Launchpad has drastically slowed down. Of course, getting bugs fixed directly in SVN is a good thing, however without a LP# attached to them, they're just "stealth fixes". ;-)
Question: How are regressions going to be treated? There are a couple that occured in the tracker in the past few days, such as:
https://bugs.launchpad.net/inkscape/+bug/184942 https://bugs.launchpad.net/inkscape/+bug/184935 https://bugs.launchpad.net/inkscape/+bug/184942
(Those all seem to be the same bug)
There may be more (or even untracked ones). Is it imperative that these be fixed? I personally think that by all means we should avoid releasing 0.46 with these present. But how are we going to proceed if the score of 500 points is reached with these bugs still open? Same question for critical bugs. Is the release held back until all of them are sorted out?
Yes, bugs that are milestoned 0.46 and assigned to an active developer will receive review even after the 500 point goal is achieved. So it's worthwhile to mark bugs you feel need addressed before the release as such. As well, if there are unreported bugs you're working on, that you want to fix before release, this is why it's good to get them registered in launchpad, milestoned, and assigned to yourself.
That said, please be selective in what you milestone at this point. There are many bugs which, while bad, developers probably won't have time to get to. Milestoned bugs should be a) highly visible to most users, b) not require massive architectural work to address, c) have an active developer assigned to them.
I periodically review the milestoned bugs and make adjustments. Many times bugs don't really need to be milestoned (just because they're not milestoned does not mean they can't be fixed, just that they won't be blocking the release). Others we can put off for a little bit, so can have their milestone set to 0.46.1 or 0.47.
Just as happened with features going up to frost, I'll be doing similarly with milestoned bugs going towards release - developers assigned to the bugs will be expected to provide status reports and estimates of time remaining. Bugs that look like they will take too long will be reviewed for alternate ways of addressing them (workarounds, disabling features, marking as experimental, ...)
Even with all this project management effort, I anticipate that there's inevitably going to be a handful of absolutely critical bugs that we're just going to have to release with. In just about every release we've put out there's been a few nasty bugs we simply didn't have the energy and/or time to solve, and we left them for the .1 release.
If people feel strongly that we still have far too many remaining bugs (and mental and others have commented on refactoring and code cleanup work needed), then one thing we could do is define these as the primary focus for 0.47. How would people feel about this?
Bryce