Hi Bill, On Fri, Mar 18, 2005 at 06:50:05AM -0600, Bill Allombert wrote: > On Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote: > > Well, the release team are not the only Debian developers with credibility, > > surely? Not everything needs to go through us; if the project has the will > > to do stable releases of these architectures, in spite of the release team > > being unwilling to delay other architectures while waiting for them, then > > it should be very possible to provide full stable releases for these > > architectures.
> And still Steve and Colin, I think that you have made a wonderful job so > far. The Vancouver plan looks like you feel yourself a failure because > your initial sarge release plan was stretched unreasonnably, but it is > completly unwarranted, and you have shown us all how to handle testing > transition in a faster and more controled way several[1] times already, > and I am sure we will benefit from this experience in the future. But > don't despair! Etch will start on a much more solid ground than Sarge. > It is much too soon to give up, Debian has enormous resource that has > yet to come into play. On the contrary, I don't feel myself a failure at all; I think there have been some unforeseen problems during the release that I wish we had been aware of sooner so that they could be planned for or dealt with earlier, but I think that sarge is going to be a solid release in good Debian tradition, and I don't think we have very far left to go. However, this has come with a high personal cost for me. The amount of effort I've been putting into the sarge release is not something that I am able to sustain for etch, and so much of it is spent on things that should *not* be the release team's direct responsibility, that I don't think we should be asking anyone else to put in this kind of effort as RM either. You pointed out in another mail that it's been asserted previously that buildd outages haven't impacted the release schedule; while that's generally true, they *have* impacted the workload of the release team, and this is what needs to change. The top three things I've spent release management time on that I shouldn't have had to are, in no discernable order: 1) processing new RC bug reports to set sarge/sid tags appropriately, so that the RC bug list for sarge bears some resemblance to reality 2) prodding maintainers to get all packages associated with library soname transitions synchronized so that they can progress into testing together (seems to require an average of 2-3 iterations, and 3-4 weeks) 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing Taken together, these probably account for more of my release management time than anything else, including actual work on release-critical bugs. The first of these issues will, I fervently hope, be addressed after sarge's release when the BTS gains support for version tracking; the code has existed for some time now and has been running elsewhere, AIUI, but hasn't been deployed to avoid delaying the sarge release. The second of these was discussed at Vancouver, but no mention was made of it in the report because there's no code to show for it; with AJ's will and enough red wine, though, we should have something else to talk about here soon. The third item is the one currently under (heated) discussion. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
