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


Christian Surchi <csurchi@mclink.it> writes:

> On 07-Nov-99 Richard Braakman wrote:
> > I think that freezing on either of those dates is not useful, due to the
> > winter festivities and the end of the world.  I'm rescheduling the
> > freeze for mid-January, the weekend of the 15th and 16th.  This will
> > be a freeze according to the original plan for potato, with all the
> > pieces ready beforehand and a fast track to a release in February.
> IMHO, this approach is absurd. Moving the freeze date of more than two months
> won't reduce the number of RC bugs. It will bring a lot of new upstream version
> and a lot of new packages in potato, therefore more bugs. 
> Slink is very outdated and we continue to postpone the new release. If we
> freeze in january we will release an old distribution. For example if Linux
> could be able to have a 2.4 kernel for Christmas, we would have potato out in
> spring with kernel 2.2.

IMHO, there is no point in freezing if we won't have working
boot-floppies expected before the end of the freeze.  Suppose we
freeze now, but it takes three more months to produce working
boot-floppies, then the released potato will be very out of date.

On the other hand, if we wait with freezing until boot-floppies looks
relatively stable, the actual freeze may be quite short.

I don't think the increase in release-critical bugs is a result of new
upstream versions being introduced.  I think it is a result of more
and more people switching to potato and _finding_ more bugs.  IMHO, we
should have regular "bug squashing parties" and other efforts to try
to reduce the RC bug count, and freeze when a release can reasonably
expected within a few weeks of freeze time.

Just my 2 cents.

	- Ruud de Rooij.
ruud de rooij | ruud@ruud.org | http://ruud.org

Reply to: