Re: 2.6.8 release
On Sat, 31 Jul 2004 13:52:17 +0200, Jens Schmalzing wrote:
> Hi,
>
> Andres Salomon writes:
>
>> There has been some talk on IRC about what kernel to release sarge
>> with; some people would prefer 2.6.8 (which hasn't been released
>> yet). If we want to do that, I would suggest getting a jump on
>> stuff now by preparing 2.6.8rc2 in svn, naming the package
>> kernel-source-2.6.8 2.6.7+2.6.8rc2, tagging and uploading to
>> experimental (with associated arch-specific packages uploaded as
>> well).
>
> If we want to do this, we must still make sure that the pruned tarball
> kernel-source-2.6.8-2.6.8.orig.tar.gz that gets into unstable is the
> vanilla tarball linux-2.6.8.tar.gz minus the non-free bits that get
> eaten by the prune script. The above suggestion runs the risk of
> getting us stuck with 2.6.8-rc2 as .orig.tar.gz, and then we have to
No; the 2.6.8-rc2 and 2.6.8 would both have their own orig.tar.gz's. We
would initially release kernel-source-2.6.8_2.6.7+2.6.8rc2 (and associated
arch images), w/ kernel-source-2.6.8_2.6.7+2.6.8rc2.orig.tar.gz. This
release would go into experimental. When 2.6.8 is released, the we upload
kernel-source-2.6.8_2.6.8 to unstable, which would have
kernel-source-2.6.8_2.6.8.orig.tar.gz. Note that the package name has not
changed; only the version has. This means no NEW wait; it also means the
orig.tar.gz may change (as it's a new upstream release). Arch-specific
image packages (at least for i386) don't have orig.tar.gz's, so that's not
really relevant; however,
kernel-image-2.6.8-1-<target>_2.6.7+2.6.8-1_i386.deb in experimental would
automatically be upgraded to
kernel-image-2.6.8-1-<target>_2.6.8-1_i386.deb in sid. This breaks ABI
compatibility; however, I don't think it's a problem, since packages in
experimental are considered, well, experimental. Since the ABI SONAME
number thingy (that's the technical name for it :) doesn't change, we're
not faced w/ a NEW wait.
> drag the patch between vanilla 2.6.8-rc2 and 2.6.8 along in the Debian
> patch. Apart from bloating the Debian patch, this leads to breakage
> for users applying it themselves to vanilla 2.6.8 (for whatever
> reason).
>
Note that one thing I'm concerned about (and probably should've mentioned
in my original post) is ia64 and alpha; getting 2.6.8 into sarge will be
tight. Assume that i386 and powerpc will be thrown in w/ kernel-source,
as those happen pretty quick. However, ia64 and alpha will probably lag
behind by at least a few days. If we release w/ 2.6.7 *and* 2.6.8, this
causes additional headaches for the security team.
>> by the time upstream releases 2.6.8, the packages will (hopefully)
>> have made it through NEW; so, we can do uploads of 2.6.8 and have it
>> enter sid immediately. The less time we have to sit around waiting
>> for things like this, the better.
>
> I don't think this is an issue at all. Last time, it took us less
> than a week to prepare and upload the first revision, and that
> included the transition to split patches. The packages entered
> unstable less than two weeks later. Here's the precise timeline:
>
> Jun 15 vanilla 2.6.7 released
> Jun 21 kernel-source-2.6.7 and kernel-image-2.6.7-powerpc uploaded
> Jun 24 kernel-source-2.6.7 and kernel-image-2.6.7-powerpc uploaded again
> Jun 25 kernel-image-2.6.7-i386 uploaded
> Jul 02 kernel-source-2.6.7 and kernel-image-2.6.7-i386 accepted
> Jul 04 kernel-image-2.6.7-powerpc accepted
>
> All in all, I would suggest to just forget this -rc business.
>
> Regards, Jens.
After chatting w/ some of the -boot people on IRC, I'm unconvinced that 2
weeks is enough time. We're talking about 4 and a half weeks total before
the packages enter testing, and that's assuming
a) 2.6.8 release happens within a week
b) it takes 2 weeks to get out of NEW
c) it takes 10 days to get through sid into testing (ie, there's no
problems w/ the initial 2.6.8-1 release).
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? :)
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).
Reply to: