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).