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

Re: Kernel 2.2 and Slink

On Sat, Feb 13, 1999 at 01:27:19PM +1000, Anthony Towns wrote:
> First, if we don't spend much time between release cycles, the only
> times you can upload *anything* is during the freeze or "just before" it.

What I'm referring to is the tendency for people to rush anything in
just before freeze, with the expectation that they can make it work
later. In other words, people seem to upload intentionally buggy new
releases just before freeze so they can put stuff into frozen as a
'bugfix' instead of a 'new release'.

> Second, have a look through the remaining release-critical bugs. The
> majority are a bunch of irritating little things against packages that
> aren't related to major changes in anything and there are a few bugs,
> notably the boot-floppies ones that simply don't get worked on outside
> of the freeze, and just plain take a while to get right.

But when I asked last week what was holding up the release, I was told
that a big part of it was the non-i386 archs. Some of that is just
keeping up with the volume of packages, and some (if I understand
rightly) is working on the patches for X -- which had some major changes
just before freeze. And why did the boot-floppies change so much? They
worked in slink, right? Was it something that _had_ to be done before we
could ship slink, or was it something that we just didn't want to wait
another year for? 

> If you're planning on saying "okay, we're in the slink freeze now, that
> means it's not long until the potato freeze -- anyone who needs to do
> major development had better start now", which seems the only way to
> avoid the former problem, you're going to have less people caring about
> fixing release critical bugs, which will make freezes take yet longer.

Several people have volunteered to work on release critical bugs. AFAIK,
there's not really anything to do. (If something does need to be done,
please shout it out.) I think the no-bug-fix argument is a red herring;
I don't think it's really unfixed bugs that are holding us up.

I have to say that's part of what I find exasperating about this
process: if someone said that in order to release slink we need to do x,
y, and z, people could work on x, y, and z. But what we have instead is
a vague idea that we're not ready to release with no concrete tasks to
divy up.

> And, personally, I'd be happier taking four months to release something
> that had real improvements, rather than just another incremental release.

It has to be one or the other? We can't even try to make real
improvements on a regular basis?

Mike Stone

Attachment: pgpqfWXpat1Yd.pgp
Description: PGP signature

Reply to: