Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 22, 2005 at 03:20:04PM -0800, Steve Langasek wrote:
> 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.
In a freeze/unstable configuration, this starts after the freeze.
(Or if you keep unstable frozen, even later.)
And during a freeze, I wouldn't expect much activity in unstable, making
the problem in the freeze/unstable configuration even smaller.
In a testing/unstable configuration, this affects all bugs including
bugs that were filed many months before the freeze.
> 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.
But even if the autobuilders of an architecture have a problem with
keeping up with unstable, they are much more likely being able to keep
up with frozen since the amount of changes is much smaller.
And it wasn't a problem if there was no autobuilder for an architecture
for two weeks during a non-freeze time.
> 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.
Transitions in unstable are easy.
The problem is usually only getting a transition into testing.
Assuming a freeze is announced early enough, it shouldn't be a big deal
ensuring that all transitions are completed before the freeze in a
freeze/unstable configuration.
> 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.
This was a goal of testing.
The woody freeze took 7 months.
Depending on how you count, the current freeze of sarge started more
than one and a half years ago, or it started "only" seven and a half
months ago - and sarge still isn't released.
As things are today, sarge will release with an X11 being more than two
years old.
This is the second release with the testing release process, and the
assumed advantages of testing still aren't visible through shorter
release cycles.
You yourself signed that statement that the testing release process is
not capable of a release cycle on the order of 12-18 months with
11 architectures.
And now two thirds of the Debian architectures should be removed from
Debian releases because you still prefer a release process that has
twice failed to show that it was superior to the former release process?
> Steve Langasek
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
Reply to: