On Tue, Mar 22, 2005 at 12:14:17PM +0100, Adrian Bunk wrote: > On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: > >... > > 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. > >... > Is it correct that none of these three points that account for most of > your release management time would exist in a release process without > testing? Misfiled bugs would be a problem in a freeze/unstable configuration, just as they are in a testing/unstable configuration. Getting binaries up-to-date across all architectures for RC bugfixes would be a problem in a frozen suite, just as it is in testing. Library soname transitions would be unlikely to happen in a freeze, but that just means any transitions that are in progress at the time all have to be dealt with *when* we freeze, even if they aren't necessary transitions. In any case, this overlooks one of the principal advantages of testing, which is that it avoids releasing software that's already 1 year out of date at the time of release. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
