On Mon, Aug 02, 2004 at 09:09:56AM +0200, Sven Luther wrote: > > 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. I think it's reasonable to ask for quicker NEW processing of a new kernel release, if it's being targetted for an upcoming release. > > 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, Yes, there is. The security team has already made it clear that they don't intend to support multiple minor kernel revisions in sarge; and d-i will pick whatever provides kernel-image-2.6 by default. So introducing a new upstream kernel as the default is not something that should be done with haste, and introducing a new upstream kernel that *won't* be the default is a waste of time from a release standpoint. If you intend to target 2.6.8 for sarge, you'll need to have a plan for getting all architectures (at least the ones built from the same source) in sync and using 2.6.8 as the *only* 2.6 kernel-image we ship. > > 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. Planning to violate the release schedule is not encouraged. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature