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

Linux 2.6.12-6 uploaded and built on all arches, waiting testing migration and futur upload plan.

Hi, ...

Now that linux 2.6.12-6 is ready to enter testing, (just waiting an RM
override for the hppa flavour rename), it would be good to declare a package
freeze of 2.6.12, and start working on 2.6.13. (well, with the exception of
the mips guys or other for 2.6.12 stuff).

(CCing debian-release, as this may concern them, or they might have input, so
i hope they will also pick up the hppa flavour rename hint above, oh, and we
should kill all 2.6.8 and 2.6.11 packages from etch and sid now).

Still, this is the right oportunity to speak about how we will handle this
kind of thing and migration from one version to another.

The most simplistic approach is to simple have only one linux-2.6 package, and
if the etch version breaks while 2.6.13 is not yet ready, we simply upload a
fix to testing-proposed-updates.

Problem with that is that t-p-u may not be operational, as i got hints about,
can someone in knowledge comment on this issue ? 

Also, the second issue is that it is a good idea to keep the older version
around, even in sid, and that the sid uploads and the testing migration thingy
is still a good thing to have. Not sure how testing-security comes into play
with this.

Now, the proposal is that, if version 2.6.N is in testing, and as soon as we
upload 2.6.N+1, we rename the old testing linux-2.6 source package into
linux-2.6.N, and continue to do uploads of it to sid, which will in due time
migrate to testing too. The only constraint is that we need to disable
meta-packages from this, or we would have double share of those, but then
maybe the meta-packages are best handled in a separate package anyway.

The benefit of this is that we would have the 2.6.N in testing, and both 2.6.N
and 2.6.N+1 in sid, and possibly 2.6.rc in experimental, or something, and
that it is easier possible to have both the last an the one before kernel in
order to check regressions and such, and that we can even keep two kernel
versions around to check for regressions and such.

Opinions on this ? 


Sven Luther

Reply to: