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 "marketshare". > * 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 lessen. > * 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 12th: * 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 kernel. 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 unreadable. > * 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. Regards, -- Sam.
Attachment:
signature.asc
Description: Digital signature