Re: bits from the release team
* Sven Luther (email@example.com) [060103 23:02]:
> On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote:
> > 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.
well, the kernel is definitly about the same level as the toolchain and
standard/base - changes can have very easily impact on the installer,
and it is not an option to remove the package if it is broken.
> > > > 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 ?
I was speaking about the installer. And usually there are lots of
last-minute changes that need to go in - not only new languages, but
lots of other small minor, but still important bug fixes.
> > 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.
Well, but then an older kernel doesn't hurt you? :P
> 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.
Of course, we have seen that the kernel build process is way more mature
now. Nobody doubts that.
> 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 :)
Well, they are definitly the relevant people for the installer. And,
frankly speaking, at least I have good experience with both of them.
> 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.
Hm, which out-of-tree modules do you consider to be release critical,
i.e. we cannot release without them?