Re: Scheduling 2.6.17-1
* dann frazier (dannf@debian.org) [060619 20:51]:
> On Mon, Jun 19, 2006 at 06:56:50PM +0200, Bastian Blank wrote:
> > On Sun, Jun 18, 2006 at 04:10:30PM -0600, dann frazier wrote:
> > > 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).
> >
> > AFAIK the plan is the following:
> > - linux-2.6 remains the metapackages, the point to the last available
> > one.
> > - linux-2.6.16 contains no metapackages.
> > - linux-latest-2.6 or so contains the metapackages to match linux-2.6.16
> > and have to go through t-p-u.
>
> fwiw, this doesn't provide a way for people to track the proposed etch
> kernel in sid, which may reduce the number of testers of that kernel
> prior to migration.
Agreed.
I think there should be agreement on which meta packages point to where
before bumping meta packages version numbers, and we should find a way
that encourages as many people as possible in both etch and unstable to
test etch kernels.
I see two ways:
1. linux-image-2.6 -> very latest, and (perhaps) something like
linux-image-etch -> etch kernels (plus in etch, linux-image-2.6 ->
etch)
2. linux-image-2.6 -> etch kernels, linux-image-2.6-latest to most
current
I think the 2nd way would give us more etch kernel testers, because most
people will just stay with linux-image-2.6 - but of course I'm a bit
biased for more etch testing (well, but most people here will have a
different bias, so I think that's ok :).
Comments?
Cheers,
Andi
BTW: I would really prefer some kind of "we're now doing foo and bar" to
debian-release prior to upload if there was no previous agreement with
the release team to prevent release team members getting panic attacks
on seeing 2.6.17 being uploaded. :)
--
http://home.arcor.de/andreas-barth/
Reply to: