Re: bits from the release team
On Wed, Jan 04, 2006 at 08:58:09AM +0100, Andreas Barth wrote:
> 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.
Nope, still it is more in the cqtegory of general base than essential
toolchain, but as you said, it is only a week.
> > > > > 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.
Indeed. I claim that the installer experience gained during the last steps of
the sarge release is worthless for the current situation, as the kernel
situation is lightyears from what it was back then. Failing on your part to
aknowledge this would be a negation or dismissal of the work done by the
kernel team during these past 6 month or so, and i would personally feel
offended, and i believe others will too, if you do this.
It is as if i was takign the boot-floppies experience to take conclusions on
the current installer.
> > > 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
Imagine an installer with a known remote security exploit, which brings up the
network early in the install process. This is microsoftian kind of practice,
and i want nothing to do with it, nor my name associated with it, and i
believe the same for you. Still we did, if i remember well, such a kernel in
the sarge installer, solely because the infrastructure didn't allow us to fix
it in a timely fashion.
This is understandable mere month or weeks before the sarge release, but
inexcusable at this point of the release process.
> > 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.
and that is an euphemism. Still there is doubt about the ability of the kernel
team to be able to think how this maturity can be extended beyond the kernel
team, and there where harsh words about our ability voiced also, which i think
are displaced. so, altough people can't honestly say they doubt it, some still
think they know better with regard to kernel matters, and don't hesitate to
patronize us on this.
> > 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.
For the installer, sure, but the generation of the d-i kernel .udebs is only
marginally of their relevance, and furthermore they don't want the
responsability associated with it, and as proof i can show you that joeyh
upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the
other architectures, defaulting it upto the porters, which are the exact same
guys doing the kernel packages. So joeyh and fjp can't have it both way.
And furthermore this is to make their live easier, so they have more time to
concentrate on more important and core d-i work.
> > 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?
Well, i guess once we kick the non-free firmware modules into the non-free
part of linux-2.6, you will reconsider that, or if there are out-of-tree
network or disk drivers. I would say that most of the wlan out-of-tree drivers
already qualify.
Friendly,
Sven Luther
Reply to: