[ First of all, apologies for the delayed response; I'm catching up after several days of FOSDEM-plague :-( ] Hi Marc, On Mon, Feb 26, 2007 at 12:16:21PM +0100, Marc 'HE' Brockschmidt wrote: >Hi, > >I would be happy to hear answers from all candidates to these questions, >but I expect that they are at least partially answered by the >platforms. Please simply point to them if you included an answer there, >even if they are not online yet. > >So, to the questions: > >* How important are regular releases for the project? In my opinion, very important. For all that we have large numbers of developers and users following unstable or testing, in my experience we have a very large userbase depending on our stable releases. From talking to lots of Debian users, a regular release is important to them. Some have coped with our releases taking longer and longer in the recent past because they love our stability, but more predictability in release timings would be wonderful. >* How important are regular stable point releases for the project? Also very important; they allow stable users to keep up-to-date with minimal pain. I'd like us to be more regular with the point releases; every 2 or 3 months would be ideal. I'm also very much hoping we can get something new working for etch point releases: installer updates with newer kernels etc. That would help solve one of the few issues with our longer release intervals, which is that new hardware is released which our kernels don't support. >* Should we fix up dak to allow point-releases for old-stable? I'm not convinced that it would be very useful, but I certainly wouldn't oppose such work. Do you think it should be done? >* 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? As I see it, the issues that have delayed etch have mainly been kernel-related. We've been waiting quite a long time for a releasable kernel to make it into the archive, and that has been blocking d-i RC2 (and hence the release itself. We've had a lot of RC bugs open, but I don't actually see them as a major release blocker. It's easy enough to remove most packages with RC bugs when we're ready, and otherwise expecting to hit 0 RC bugs for release is never a realistic goal. I don't think we need to restructure the release process necessarily, but maybe we do need to get more people involved and caring about the process/date earlier on. I have personally been *very* impressed with the etch release team, and I wish more people could be as dedicated. The big difference this time (imho) is that once sarge released we did *not* just let things go for a while, hoping to clean up later. This time, migrations to testing have mostly been very well managed, with bigger updates closely monitored and controlled throughout the cycle. That has made a huge difference, and I applaud the effort involved on all sides. >* 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"] A compromise would be nice, and should certainly be possible. If we can agree upon and set a *reasonable* expected date, most of our issues should be predictable enough to allow us to freeze appropriate versions of all the larger package sets (Gnome, KDE, kernel, X, etc.) with enough time to make that date *and* still meet our expected high quality standards. -- Steve McIntyre, Cambridge, UK. steve@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Attachment:
signature.asc
Description: Digital signature