Re: Questions to all candidates: Release importance, release blockers, release quality
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.
vorlon@debian.org http://www.debian.org/
Reply to: