On Fri, Mar 02, 2007 at 03:36:10AM +0100, Sam Hocevar wrote: > > Only after the freeze is it possible to do certain kinds of systematic QA, > > such as checking for build failures within testing. Have you taken that > > into account when deeming that a decline of 10-20 bugs over two months > > indicates too early of a freeze? Have you factored in the introduction of > > new RC bugs into testing without detection, prior to the freeze?
> I was aware of all these parameters, but their potential impact on > the RC bug evolution was all but clear. Again, I would have loved a > graph of newly found bugs, downgraded ones, bugs fixed by a transition > to testing, etc. to know the trend for all variables. And since our > target was 0 RC bugs /in Etch/ I was under the impression that we should > focus on the RC bug count /in Etch/, which was the main reason why I > thought freezing at 116 bugs in Etch while it was planned to do it at 80 > was a bit too early. FWIW, the determination to freeze when we did was made partly in response to the perception that we had reached the break-even point, where the rate at which new RC bugs were being introduced into testing due to the lack of freeze was comparable to the rate at which RC bugfixes were being uploaded. As has been discussed, we don't have much hard data on this (even analysis of bug openings and closures wouldn't give us this directly since we would have to know which bugs are new and which are just newly reported), so all I can offer is the result of our eyeballing at the time. > That said, a buffer does not mean we should no longer care about > the schedule (like we more or less did) if the deadline is missed. The > workplan should be updated to make up for the delay, priorities should > be shifted and goals reconsidered. Unless of course we no longer care > about the release date. At that point, there was insufficient data to give a reasonable estimate of the time it would take to get a releasable kernel sorted out. Having missed the original target, we weren't inclined to post new release schedules that we had a low probability of being able to meet. > > > By dealing with RC bugs by popularity contest instead of date or bug > > > number, we can reach a higher quality faster. > > Judging by the number of people who stepped forward to help with the > > release-critical bugs on the kernel, I guess the kernel isn't very popular > > with developers. Is that the popularity contest you mean? > No, by popularity contest I mean popcon.d.o: focus on bugs in > packages that affect the most people first. Or did I misunderstand your > objection? To state it plainly: the blocker for the etch release for the past 2 months or so has been the kernel. This was known, and it was stated. I don't remember seeing anyone from outside the kernel team step forward to tackle any of the kernel's RC bugs. This is pretty understandable -- we already have a large kernel team, and the package is not exactly readily NMUable, so trying to focus the whole project's attention on the kernel sounds like a classic mythical-man-month recipe for disaster, in addition to being a pretty huge time investment for any outside developer because of the kernel package's high learning curve. So what do you think should have been done differently in terms of release management that would have helped keep the release target? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
