[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions to all candidates: Release importance, release blockers, release quality

On Mon, Feb 26, 2007, Marc 'HE' Brockschmidt wrote:

> * How important are regular releases for the project?

   Very. Regular releases make our users faithful, prevent them from
getting bored and trying something else. They also give credibility when
approaching hardware vendors (they don't want to support old versions of
Linux or other components) and even proprietary software vendors from
which we would like certifications.

   I think our long release process is the main cause for our declining

> * How important are regular stable point releases for the project?

   Very important, too (though if workforce were to become an issue,
I'd still rather have regular releases). But if we have more frequent
releases, the work needed for stable point releases will mathematically

> * Should we fix up dak to allow point-releases for old-stable?

   Yes. Again, if we are to have regular releases, I hope it will mean
more frequent releases (eg. 12 months or even fewer) in which case
old-stable will not be /that/ old, and will require attention.

> * 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

  * we announced a bogus release date. I know not everyone agrees on
  who is responsible for that announcement, but if we end up saying etch
  is late, it's obviously late relative to some date. I know it takes
  pride to take back an announcement, but my feeling is that admitting
  earlier on that the initial claim was unrealistic would have caused
  less PR damage.

  * we ignored both the average evolution of RC bugs from previous
  releases and the fact that on every release we're going twice as
  slowly as our expectations. The RC bug count monitoring was quite
  cloudy, with at least three different sources of information and
  no precise measurement (for instance aba, in one of his dunc-tank
  reports, mentioned that there was no tool to monitor how many bugs
  were opened and how many were closed, only the delta was plotted;
  I would have expected such a tool to appear during the dunc-tank
  process but it hasn't).

  * although I am unable to quantify it, the dunc-tank controversy
  certainly helped delay etch, whoever was responsible for it. For
  instance, Joss orphaned libpng out of frustration and it was adopted
  by Anibal who screwed up a few uploads because he was unfamiliar with
  the package; certainly Anibal is partly responsible for the RC bugs
  that ensued, yet others will claim that Joss is responsible because he
  abandoned libpng and/or was stubborn about dunc-tank, and some others
  will blame dunc-tank for causing Joss to reduce his involvement. This
  is just an isolated example that is not meant to illustrate all the
  possible consequences but I think it clearly shows how the responsi-
  bilities are shared.

  * 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.]

  * [...] <- [here was something that TTBOMK was only discussed on
  debian-private and whose decision to disclose is not mine, you can
  contact me by email if you feel it's important.]

  * maybe we miscalculated our priorities: the installer and the kernel
  were far worse blockers than the RC bugs on hardly used packages, yet
  the release timeline sticked to the RC bug count. Now I haven't
  followed what these teams were doing and I don't mean to imply that
  the RMs weren't working on these issues, but I have seen little
  communication from them about the remaining issues in d-i and the

   And yes, I think it is necessary to restructure the release process.
I will comment about it in another email or this one will become quite

> * 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). For that we need to
rethink what "quality" means. Quality is not a mere RC bug count, there
are other factors even when only looking at bugs. We have never shipped
a zero-bug release, and we will never, some normal bugs are hurting more
than RC bugs, and there are bugs that no developer or user cares about.
By dealing with RC bugs by popularity contest instead of date or bug
number, we can reach a higher quality faster.


Attachment: signature.asc
Description: Digital signature

Reply to: