Re: 2.6.8 release
On Sun, Aug 01, 2004 at 09:28:46PM -0400, Andres Salomon wrote:
> 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
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.
> 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 :/
> 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.
> 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.
Friendly,
Sven Luther
>
>
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: