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

Re: testing and no release schedule



On Fri, Mar 26, 2004 at 02:40:43PM -0600, Steve Greenland wrote:
> On 26-Mar-04, 14:07 (CST), Adrian Bunk <bunk@fs.tum.de> wrote: 
> > Halloween 2002 was announced as the date for the feature freeze for
> > kernel 2.6 months before, and after this date most effort was spent in 
> > stabilizing the kernel.
> > Looking at kernel 2.6 my impresion is that this was a good way.
> The kernel has someone with the power to say "Yes, this change goes
> in", and "No, this change must wait". No one in Debian has that power.

That's not true. The RM has the authority, and ftpmaster has the ability
to ensure the RM can exercise that authority. It's used for all uploads
to stable.

The reason we don't like that is that freezes *suck*. If X is going to
take five months to stabilise, and a new release of KDE comes out one
month into that that takes just one month to stabilise, how does it
make any sense to block an updated KDE? Or conversely? They suck worse
if you're the RM, because you have to approve _every single upload_,
probably for months on end. For potato, for the five or six weeks I was
acting RM, that was some 300 changes; since potato the archive's grown
by three or four times, and the potato freeze went for something like
eight months, not six weeks. And that's not to mention that for potato,
we thought a hundred RC bugs was almost impossible to manage; and weren't
even trying to ensure absolutely everything had its dependencies met,
let alone its build-dependencies.

At the moment, d-i is still acting as a showstopper for a release; so
it's not terribly worth worrying about figuring out better ways to fix
RC bugs elsewhere; they're simply not the major problem.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

             Linux.conf.au 2004 -- Because we could.
           http://conf.linux.org.au/ -- Jan 12-17, 2004

Attachment: signature.asc
Description: Digital signature


Reply to: