On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk <[EMAIL PROTECTED]> 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
To the extent that maintainers accept upstream's crack-of-the-day into sid, relying on a not-for-sarge mechanism instead of letting the bugs pile up upstream, the testing scripts do worsen the traffic late in the release cycle. Beats binge-purge, if you ask me, but YMMV. During a freeze-by-whatever-mechanism, becoming informed about whether allowing a given update would improve or worsen the situation takes effort; sarge/sid tags are part of that analysis. I think Steve is mostly saying that scrubbing the raw bug report data by disambiguating sarge and sid bugs shouldn't be the release manager's job. > > 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) Yep, this is a lot of work. The alternatives are unbuildable packages (left behind by a transition) or multiple versions of core libraries. The relevant packaging teams are getting the hang of it, though, and testing is a good tool for measuring progress towards an engineered release. Again, I think Steve wants this to be more of a maintainer/porter responsibility during more of the cycle. > > 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 Comments elsewhere; but I certainly don't think this is caused by testing. Don't shoot the messenger. > > Taken together, these probably account for more of my release management > > time than anything else, including actual work on release-critical bugs. Well, if it were efficient for the RM to be doing bug fixes himself, something would be broken. :-) > 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? Doubtless the timing patterns would be different; but if you want sarge not to suck, it has to follow a meaningful bug metric down to (near) zero, contain a choreographed release of libraries and desktop integration, and the polish that comes from fixing bugs all the way instead of ignoring corner cases. None of these challenges is unique to a testing-mediated release process. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]