Re: A suggestion for the woody freeze
On Thu, Jan 17, 2002 at 01:32:12PM +0000, 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?
>
> 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
> 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.
> 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.
My personal opinion is that all we need more NMU and BS parties.
And that all maintainers should _now_ suspend/reduce their own pkg
maintainment to concetrate on RC bugs.
I cannot think that around 600 active developers cannot solve them.
Moreover, for some bugs if a fix cannot be find soon, maybe a 'workaround'
could be considered. Eg. the problem of no locales generation at installation
time has an obvious post-installation workaround, i.e.
dpkg-reconfigure locales.
What about a "KNOWN PROBLEMS AND WORKAROUNDS" document to distribute
along with the new release to point problems and suggests temporary solutions?
--
Francesco P. Lovergine
Reply to: