Re: Questions to all candidates: Release importance, release blockers, release quality
On Tue, Feb 27, 2007 at 07:25:36PM +0100, Sam Hocevar wrote:
> > * Could you list the issues that you think delayed the release of etch?
> > Do you think that we need to restructure the release process for lenny
> > to avoid these? If yes, how?
> From an email I sent to madduck for a recent talk of his, on February
> 12th:
> * we announced a bogus release date. I know not everyone agrees on
> who is responsible for that announcement,
Who do you believe is responsible for that announcement?
> * we froze too early (at 116 RC bugs in etch), ignoring the fact that
> once we freeze, package transitions mean more work for the developers
> and more work for the release maintainers. Two months after the
> freeze, we [were] down by 10 or 20 RC bugs, not much more. [Today it's
> getting a lot better.]
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?
> > * Do you think that a release of high quality is more important than a
> > timely release? [ie: Should we switch from "when it's ready" to "when
> > we said we would release"]
> I do think a release of high quality is more important than a timely
> release. However, I also think it should be possible to stick to a given
> date (with the usual two-month buffer, of course).
If you think there's a "usual two-month buffer" that applies to release date
targets, why, before we'd even reached the original target release date,
were you publicly mocking the release team's efforts in your blog?
I appreciate your support as a maintainer in dealing with release-critical
bugs that affected your packages. But why should anyone who cares about
Debian's stable releases vote for you if that's the sort of support you're
going to show for the release team as a public figure?
> 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?
--
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: