Re: bits from the release team
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. :)
[re-arranged the quote]
* Sven Luther (email@example.com) [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.
> > 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
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.
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.
> 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.