On Tue, Mar 22, 2005 at 02:55:17PM +0000, Michael K. Edwards wrote:
> 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.
Without testing, there was no need for anyone to do such a
distinguishing before the freeze starts.
And if you'd (in a relesase process without testing) freeze unstable for
some time after the beginning of the freeze, you could get the point
when frozen starts diverging from unstable even later.
> > > 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.
As I've already said in another email:
Transitions of API-compatible libraries are a pain _only_ due to
testing. In unstable, such a transition can easily be done within a few
days.
Remember the libtiff transition.
Look at the various libexif transitions.
...
The transition in unstable is trivial (changing the build dependencies
in the packages).
The complete transition into testing is a pain (in the libtiff case
Steve cheated by introducing a second libtiff source package but it
still took some time).
> > > 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.
>...
Steve's talking about bugs already fixed in unstable that might still be
present in testing.
Why do you think this wasn't caused by testing?
> Cheers,
> - Michael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
