Re: bits from the release team
On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote:
> (forgot to CC d-kernel on this)
>
> On Tuesday 03 January 2006 22:02, Sven Luther wrote:
> > 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.
>
> 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just
> starting to get implemented).
>
> I remember we did consider using 2.6.10 instead of 2.6.8 and decided not
> to mainly because it was not really that much better than 2.6.8.
> As I remember it, this was a joint decision by the kernel team, release
> managers and the d-i developers. Not something that the kernel team were
> really pushing and was blocked by some assholes from the d-i team who did
> not want to cooperate.
Well, i remember joeyh vetoing it because it would take at least a month to
get the change done, and i believe we didn't really push for it because the
infrastructure was a mess back then. This has changed.
The one point that put me up, is that we should have gotten that security
update in, but this was also vetoed for the same month-long delay in the
kernel/d-i upgrade process. The kernel team has reduced that delay to less
than 24hours now for the release arches, but there is still work to be done on
the d-i side of it, and more specifically with the module .udebs, which could
be uploaded quickly, but rely on the porters doing very unfriendly drudge
work.
My believe is that this kind of thing should be as much automated as possible,
to let the few ressource we have be used where best it should, a little work
at the start which will pay off forever after, this is what computers and
programming is for, to make the task of the users and programmers easier, i
think we all agree with that, or we would still be using boot-floppies :)
> The first kernel after 2.6.8 that was a real improvement was 2.6.12 and
> that was released definitely too late for Sarge.
Agreed, the issue is the common infrastrucure, and the cost the previous
situation has, and the repercusion of this cost on stable-security.
> > Already it should be possible, provided the d-i guys get their act
> > together, to have a new d-i .udeb sets within 48 hours or less of a new
> > upstream kernel release, altough the image build may take longer, and
> > we hope to get the external modules and patches streamlined by then.
>
> This is an extremely bad way to get friendly cooperation and discussion
> about changing anything.
:) Well, we could have released 2.6.15 with .udeb modules included, which
would have been less friendly even.
> Producing new udebs for all architectures for d-i can be done quite fast,
It could, joeyh even told me it could be easily automated, and Kamion
mentioned me he is already doing part of what is needed for that automation
(namely building module .udebs without installing the kernel images), but upto
now it is still a pain, and takes over a week or two to get done, this was the
case for both 2.6.12, and 2.6.14, and why is that ? Because the porters are
slackers is not really the right reply to this.
> as evidenced by the recent uploads for 2.6.14, provided the porters
> taking care of the udebs for their architecture . I expect little
> problems or delay for 2.6.15.
Indeed, and this is the crux of the problem, you put all the responsability on
the porters, while there is really no porter work needed at all. it is only
the nature of the non-unified package that the mainstream arch gets build
quickly, and the non-mainstream arches get bit-rotten until there is an
urgency and the porters get kicked. This is the process problem we are facing,
and i think we can solve in a way satisfactory to the d-i team.
My plan is to come up with something for the 2.6.16 timeframe, which you can
then review, and if it works out well, be used shortly afterward. Etch should
release with 2.6.18 i believe, with the current timeframe, so we have two
versions afterward to sort things out.
> As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for
> i386.
And exactly this is the bug, and not the feature, it did happen quite fast for
i386, but nobody cared about the other arches, like before the i386 kernel
came out quite fast, but other arches came out with a more or less longer
delay. Compare with same day upload on 9 of the 12 main debian arches ?
> Yes, we did wait a while before updating to 2.6.14, but that was
> mainly because d-i itself first had to prepare its userland for the
> removal of devfs.
The 2.6.12 to 2.6.14 upgrade was indeed very very painful because of the devfs
removal and thus initrd-tools replacement, i am well placed to know about
that.
> So please, get off your hobbyhorse and stop pissing people off with
> unfounded statements.
He, so, there is no problem, and the situation is perfect, and you prefer to
hide and shoot the messenger :)
Friendly,
Sven Luther
Reply to: