[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting



On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk <bunk@stusta.de> 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



Reply to: