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

Re: A suggestion for the woody freeze



On 17 Jan 2002, Phil Blundell wrote:

> On Thu, 2002-01-17 at 13:11, Adrian Bunk wrote:
> > Jan 25.-27. bug squashing party in preparation of the freeze
> >
> > Feb 1.     freeze; start of the first bug squashing cycle
> >            every upload to frozen must be approved by the release manager
> >
> > Feb 15.    start of the second bug squashing cycle
> >
> > Mar 1.     start of the third bug squashing cycle;
> >            only fixes for RC bugs are allowed after this date
> >
> > June       estimated release date for 3.0r0
>
> What do you feel is the advantage of this scheme?

- We work on getting all packages ready at the same time, IOW:
  We don't wait for all packages in base or in tasks to be bug-free before
  we start to focus on the other packages.
- There's a definition of what has to be done at which time.

> As far as I can tell, the problem we have isn't so much that new, buggy
> versions of supposedly-frozen packages are leaking into testing; more

New upstream versions might be buggy or they might simply break other
pacakges, like e.g. the latest version of python2.1-xml that caused some
breakage in boot-floppies (see #127405).

> that RC bugs against packages already in testing are just not getting
> fixed in a timely manner.  So the choices are:
>
> 1) Pull the affected packages out of testing, and move forward without
> them.  This probably isn't appropriate for packages in base, which are
> the ones causing us trouble right now, but seems like the right way to
> deal with "extra" and "optional" priorities.
> 2) Make some best-effort attempt to fix the bugs, but don't allow them
> to hold up the release; just ship the buggy packages if that's all we've
> got.

Wit the scheme I describe every RC bugs has to be fixed within a maximum
amount of 2+2=4 weeks or the package will be removed. The possible removal
is visible to _all_ developers and NMUs are explicitely allowed one week
before the package might be removed - and there's a planned bug squashing
party that tries to fix most of the RC bugs. It's clear that similar to
the potato freeze there might be a handful RC bugs in packages we can't
remove (e.g. gcc or glibc) left after the two weeks if they are really
hard to fix, but after the first bug squashing cycle all other RC bugs
that were older than two weeks are resolved (by either fixing/downgrading
a bug or by removing the package).

One effect will be that many people will happily start to fix bugs when
they see that applications they like will be removed in one week when the
RC bugs aren't fixed...

> 3) Delay the release in hopes that the bugs will get fixed.
>
> So far we've been doing (3), with perhaps limited success.  If you feel
> that (2) is more appropriate, you can get this effect by liaising with
> maintainers and bug submitters to downgrade bug severities in some
> suitable fashion.

The big problem is that it's hard for a single person to go through the
whole bug list and there are even bugs in base packages where I'm missing
the knowledge to fix them or where I can't do anything (e.g. AFAIR Ben is
waiting for the next upstream release of glibc to fix the security bug in
unstable). And currently I'm missing the motivation to go through the RC
bugs only to see that this doesn't result in a step forward the release of
woody - as already said in another mail I've already done much work both
on my packages and in bug squashing parties and also in partial going
through the lists of RC bugs only to see that the freeze still stalled.

> p.

cu
Adrian





Reply to: