Re: Scheduling 2.6.17-1
On Sun, Jun 18, 2006 at 11:39:16PM +0200, Frederik Schueler wrote:
> Hello,
>
> On Sun, Jun 18, 2006 at 11:29:32AM -0600, dann frazier wrote:
> > Is the plan to do a "linux-2.6.16" upload at the same time, or does
> > this imply a decision to use >= 2.6.17 in etch?
>
> We have not yet decided about what to use for etch. There has not been
> any more commitment towards a long-term support for 2.6.16 on LKML, but
> maybe the last word is not spoken here yet. Anyone who knows more about
> it?
The last message I've seen on the subject is Adrian saying this will
start *after* 2.6.17 releases - so it should start RSN.
> 1. we upload 2 source packages: linux-2.6.16 version 2.6.16-15 and
> linux-2.6 version 2.6.17-1. This will allow us to upload 2.6.17 ASAP,
> and to continue 2.6.16 support until the etch release kernel decision is
> made.
>
> 2. we upload linux-2.6 2.6.16-15 on Monday with urgency=high and have it
> added to testing ASAP, and upload linux-2.6.17-1 on Friday (5 days
> later), probably with XEN images in place, and one round of NEW less.
> With this option, taking care of 2.6.16 in testing could be done through
> t-p-u uploads.
>
>
> I personally would like to follow option #1: We could backport
> sparc/niagara and smp-alt support if 2.6.16 gets long-term support, we
> would have a stable kernel for etch until 2.6.17 stabilizes, and we had
> enough time to decide which kernel to release with.
Yes, I like that plan too. I think we will want to do a linux-2.6.X
pkg for whatever version we want to get into etch, so we might as well
do it now & work out any issues.
The only technical issue is getting the meta packages to play well. I
think rough consensus was to leave the metapackages as-is in
linux-2.6.16 and either 1) drop meta packages from linux-2.6 >= 2.6.17
or 2) create separate metapackages for linux-2.6 (linux-image-2.6-686-sid,
for example).
--
dann frazier
Reply to: