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

Re: 2.6.8 release



On Mon, 02 Aug 2004 09:09:56 +0200, Sven Luther wrote:

> 
> With proper cooperation from the ftp-masters, this could happen much faster. I
> have asked in the past that the kernel packages get the same favorite
> treatment as the d-i packages, but nobody ever bothered to react on this. 
>

This is a big *if*.

 
>> c) it takes 10 days to get through sid into testing (ie, there's no
>> problems w/ the initial 2.6.8-1 release).
> 
> There should be no major problem to upload with priority high, and use 2 days
> for this, since there is not 2.6.8 package in testing which would break
> because of this, the 2.6.7 package would stay. I asked Jens to do high
> priority upload for 2.6.7-3, and the package ended in testing 3 days later, he
> forgot to do the same for the 2.6.7-4 upload though, and so it will probably
> miss the d-i beta release :/
> 

This is another big *if*.  Sure, if we set priority=high, it could only
take 2 days.. unless there's an RC bug.  Or we need to do a rebuild.  Or
any number of things.  


>> If there's a problem, we need to do another kernel-source release for
>> some reason, NEW processing takes longer than 2 weeks, 2.6.8 takes
>> longer than a week (or two) to release, etc, we're screwed.  We cut
>> this time down by releasing rc2, or by requesting that the FTP Masters
>> special-case kernel-*2.6.8* stuff.  Which of these seems like the
>> easier, foolproof way to do things? :)
> 
> ftp-masters special casing 2.6.8. But an upload to experimental would be
> still good to help pave the way to the real release, and given the
> current subversion build system and small patches, there may even be
> chance that the 2.6.8 release builds with few or only minor
> modifications to the patches.
> 

*blink*.  Are you trying to be difficult?  FTP Masters special casing
2.6.8 is the foolproof way?  I assume you've talked w/ FTP Masters, then,
and they're willing to do this?  Otherwise, you're simply theorizing.

 
>> We should find out within the next few days when main freezes. The
>> release people with whom I've talked w/ don't seem interested in
>> special-casing kernel packages once main is frozen (and I can't blame
>> them).
> 
> I have the belief that if our kernel people believe that 2.6.8 is the
> kernel we should use, based on the fact that security would be easier if
> redhat is releasing with it too, and the fact that it is mostly bugfix
> and stability improvement over 2.6.7, then i believe it is worth
> delaying the release a few days for this. There will probably be enough
> other stuff delaying the release that we can afford to wait for this.

No, it is not worth delaying the release if we can avoid it.  Hoping the
FTP Masters will jump to attention when we demand it is ignoring what
history has shown us.  

Furthermore, while our kernel people may believe that 2.6.8 is the kernel
we should use, without having users actually use it, there's no way to
tell how stable it is.  Bugfixes tend to introduce other bugs; any
programmer can attest to that.  Having 2.6.8 sitting in NEW, with no one
using it, and then pushing it through testing in 2 days is a worse idea
than having 2.6.8rc (or bk snapshot) sitting in experimental, then having
2.6.8 enter unstable immediately, with the additional time that it
would've spent in NEW to allow for people to test it.





Reply to: