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

Re: 2.6.8 release



On Mon, Aug 02, 2004 at 01:57:50AM -0700, Steve Langasek wrote:
> 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.

I think this was warranted for 2.6.7 also, and even asked so, but was vastly
ignored.

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

Bah, so we upload as usual, and we manually hint the 2.6.8 package to enter
testing If we decide to go that way.

Still, the security team may want to have only one kernel-source package for
2.6, but i guess it will make things easier for them if they go the 2.6.8 way,
especially if the kernel team decides that this may be the right solution.

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

No, but let's be realist. The woody release schedule was also announced in a
hurry (of the no info for month, and then we freeze tomorrow), and then we
waited almost three month without news for the security infrastructure.

Also, reading the mail announcing a freeze on august 2 today is not exactly
helpfull, is it ? If it would have been a week or two delay between the base
freeze and the rest of the freeze, then ok, but 2 days ? 

Friendly,

Sven Luther



Reply to: