Re: bits from the release team
On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote:
> Hi,
>
> thanks for your mail. I just want to point out that we published the
> timeline already back in October, but of course, that shouldn't refrain
> us from changing it if this is necessary. :)
Yeah, i was already chidded (?) that my mail was too inflamatory, this was not
the intention, altough i wrote it such to get some reaction upto a point :)
> [re-arranged the quote]
> * Sven Luther (sven.luther@wanadoo.fr) [060103 22:03]:
> > On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > > N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels
> > > N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including
> > > e.g. cdbs)
> >
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
>
> Hm, I'm quite sure we had some good reason for this; however, I cannot
> really remember why we put the kernel to the essential tool chain. On
:)
> the other hand side, the difference is only one week - and if nothing is
> broken by that, we can freeze the kernel at N-110 also.
i think comparing the kernel with the toolchain is overkill, if nothing else a
last minute change in the toolchain will need a kernel recompile anyway maybe.
I do confess that i read June 30 at first, and this seemed much less
acceptable to me.
> > > N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > > N-45 = Wed 18 Oct 06: general freeze [about 2 months after base
> > > freeze, d-i RC]
> > > N = Mon 4 Dec 06: release [1.5 months for the general freeze]
> >
> > We will have a kernel which is outdated by two versions at release time with
> > this plan, since there are about 1 kernel upstream release every 2 month.
>
> Well, if we want to release with a newer kernel, we need to make sure
> d-i doesn't stumble over it. Experience tells us that there are enough
What experience ? There is no way of common measure between todays situation
and what happened in the pre-sarge timeframe, and we (i, but some of the
kernel team at least agreed with that) fully expect to get things working out
nicely well before the release date, so that there would be a much reduced
impact from the kernel upload on the d-i build schedule. Remember i proposed
the common infrastructure already in marsh/april last year, but was voted done
for the sarge release on it (with some no-kind words even).
The main issue will be one of testing the kernel and d-i built with it, but
there should be no technical hurdles which would cause month-long delays.
> last-minutes changes to the installer that we cannot avoid to better not
> change the kernel; if the installer team (i.e. Joey Hess or Frans Pop)
> tell us otherwise, we can of course adjust our plannings. However,
> there will be a minimum periode where we just need to freeze everything
> to get enough testing to the proposed release.
Indeed. The d-i team usually says "no" outright to any kind of proposal of
this kind, so it is up to the kernel team to come up with an implementation
which convinces them :) The release team deserves to be informed about the
possibility though.
> Also, the kernel will be outdated sooner or later anyways - so, if after
> one year the kernel is 12 or 14 months old is not too much a difference.
Hehe, me runs sid kernels installed almost as is on all my sarge systems
indeed, just with rebuild yaird and mininmally backported udev. But still, it
is an image issue, and i believe the kernel team would be more happy if the
"obsolet the day it comes out" stigma debian has had in the past doesn't touch
us. Also, you will pay in maintenance cost for those few month difference
during all the etch livetime, guess who will be ending doing this work ?
> > So, we will be asking the question about the upgradability of the kernel later
> > during this release process, and i believe that it is not something which
> > should be ignored.
>
> Well, we as release team first believe what is told us by the relevant
> maintainers. Our current status is that kernel upgrades late in the
> release process (especially after the d-i RC) are rather painfull.
Indeed, but you have only the sarge experience to go by, and taking the sarge
experience on this is hardly fair to the huge amount the kernel team has
devoted to streamline the process. Also, i don't really believe joeyh and fjp
are really the relevant maintainers with regard to the debian kernel and its
application, since they lack the vision of how things could go better, or more
thruthfully, probably lack the time and motivation to think really about the
issue, and why should they, it is the kernel team jobs :)
d-i is only a part of the problem anyway, and i believe the less problematic.
out-of-tree modules and third-party patches are a worse mess.
Friendly,
Sven Luther
Reply to: