Re: bits from the release team

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels

Why do you put the kernel together with the essential toolchain freeze, it
should be together with the rest of base, i believe.

> N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
>                         e.g. cdbs)
> 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.

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. Already you are considering upgrading the sarge kernel
which has some trouble booting on a rather non-negligible quantity of
hardware, so having a two version outdated kernel at release time is not nice.

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.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Margarita Manterola
On 1/3/06, Sven Luther <[hidden email]> wrote:

> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.
> [...]
> 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.
>
> 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. Already you are considering upgrading the sarge kernel
> which has some trouble booting on a rather non-negligible quantity of
> hardware, so having a two version outdated kernel at release time is not nice.

I really don't think that having a four months out-dated kernel is
that bad.  What is really important is to have stable kernels.  Past
experience with the modified 2.6 release policy has shown that some
2.6 kernels are pretty stable and some others are quite crappy.

So, I'd say it's better to give some time to be sure that the kernel
that is shipping with Debian's stable distribution is really a stable
kernel, and not a crappy one.  I don't think you can tell the
difference before this version of the kernel reaches a big number of
people, and therefore, it does need time (frozen, in testing).

However, if while preparing the release, the frozen kernel would show
up as being a crappy one, the release managers might allow for a new
kernel to enter testing.  But this is only a hypothetical case, and I
expect it would be carefully evaluated before it actually happened.


--
Besos,
Marga

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Andreas Barth
In reply to this post by Sven Luther
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. :)


[re-arranged the quote]
* Sven Luther ([hidden email]) [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.


Cheers,
Andi
--
  http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Maximilian Attems-3
In reply to this post by Sven Luther
On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
>
> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.

the kernel is an essential piece of our release,
makes sense to have it in tune with everchanging userspace interfaces
(alsa, udev to name a few).
 
> > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> >                         e.g. cdbs)
> > 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.

we had the chance for sarge, but we weren't ready.
for etch we will work for our best to be ready.

please don't rush out such mails without consensual position.

--
maks


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Frans Pop
In reply to this post by Sven Luther
(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.

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.

> 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.
Producing new udebs for all architectures for d-i can be done quite fast,
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.

As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for
i386. 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.

So please, get off your hobbyhorse and stop pissing people off with
unfounded statements.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Andreas Barth
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 ([hidden email]) [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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Maximilian Attems-3
On Tue, Jan 03, 2006 at 10:32:12PM +0100, Maximilian Attems wrote:

> On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote:
> > On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
> >
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
>
> the kernel is an essential piece of our release,
> makes sense to have it in tune with everchanging userspace interfaces
> (alsa, udev to name a few).

Indeed, that is why it is part of base, but putting it in comparison with the
toolchain (glibc, gcc, etc) is overkill.

> > > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> > >                         e.g. cdbs)
> > > 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.
>
> we had the chance for sarge, but we weren't ready.

Due in big part to the messed up kernel situation we inherited from in sarge,
remember i proposed delaying sarge to get the unified kernel infrastructure :)

> for etch we will work for our best to be ready.

indeed.

> please don't rush out such mails without consensual position.

like bow and smile and wait forever ? This is not i believe the debian way of
handling things, and i am certainly not the only one taking this kind of
approach, and much more involved and whatever DDs than me have done it like
that, so ...

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Frans Pop
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



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Margarita Manterola
On Tue, Jan 03, 2006 at 06:26:02PM -0300, Margarita Manterola wrote:

> On 1/3/06, Sven Luther <[hidden email]> wrote:
>
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
> > [...]
> > 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.
> >
> > 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. Already you are considering upgrading the sarge kernel
> > which has some trouble booting on a rather non-negligible quantity of
> > hardware, so having a two version outdated kernel at release time is not nice.
>
> I really don't think that having a four months out-dated kernel is
> that bad.  What is really important is to have stable kernels.  Past
> experience with the modified 2.6 release policy has shown that some
> 2.6 kernels are pretty stable and some others are quite crappy.

Indeed, but that would be something the kernel team is best placed to decide,
and if a given unstable kernel is crappy, we won't allow it in testing, its
that simple.

> So, I'd say it's better to give some time to be sure that the kernel
> that is shipping with Debian's stable distribution is really a stable
> kernel, and not a crappy one.  I don't think you can tell the
> difference before this version of the kernel reaches a big number of
> people, and therefore, it does need time (frozen, in testing).

Indeed, unstable is such a place, but is 4 month too much of a time to find
out, and would a month or two be enough, i do believe this.

> However, if while preparing the release, the frozen kernel would show
> up as being a crappy one, the release managers might allow for a new
> kernel to enter testing.  But this is only a hypothetical case, and I
> expect it would be carefully evaluated before it actually happened.

The crappy kernel would never enter testing in the first place, as testing has
always been done on unstable. See 2.6.14 is out for over 2 month now, and it
didn't reach testing, and never will now that 2.6.15 is out, because the
devfs/initrd-tool situation, and this was the right thing to do.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Frans Pop
In reply to this post by Sven Luther
On Tuesday 03 January 2006 23:01, Sven Luther wrote:
> 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 :)

Bullshit.
We (d-i team, mainly Joey) gave very good reasons why we thought the
proposal was not good and would result in more problems than it solved.
That you choose to structurally ignore the opinions, comments and
objections by others who are a lot more knowledgeable about the _other_
area in Debian impacted by the proposal is typical.
Your half-baked proposals may look good from a kernel maintenance
viewpoint, but in our opinion they have a negative impact on the d-i side
of the equation.

Rejecting a badly thought out proposal is _not_ the same as saying no
outright.

I'm not going to repeat the arguments here. They can be found in the
archives.

Your attitude does nothing to motivate me to work on this.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
On Tue, Jan 03, 2006 at 11:33:44PM +0100, Frans Pop wrote:
> On Tuesday 03 January 2006 23:01, Sven Luther wrote:
> > 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 :)
>
> Bullshit.
> We (d-i team, mainly Joey) gave very good reasons why we thought the
> proposal was not good and would result in more problems than it solved.

You did indeed give good reasons why having the one .udeb per module plan i
follhardly proposed would not work.

The current proposal is about simply using the same .udeb organisation and
move it inside the linux-2.6 common package, which is something that works out
just fine for ubuntu even, but which the current linux-2.6 common package
infrastructure could also handle. The only reason i saw against this was a
mail from joeyh mentioning ease of moving modules around inside .udebs, and
that this would be easier under the d-i umbrella than if it is inside the
kernel, and naturally the old sarge-time brokeness in the archive
infrastructure, which is presumably fixed by now, or should be fixed for etch.

I believe that this is indeed an argument, but which is outweighted by the
benefit especially on the port situation, i believe, and the reason i come
back with this times after time :)

> That you choose to structurally ignore the opinions, comments and
> objections by others who are a lot more knowledgeable about the _other_
> area in Debian impacted by the proposal is typical.

Yeah, i am an idiot and you know best, especially when you fail to clearly
understand what i propose and chose to reject it on the basis of what you
think i propose, this is probably due in part to some lacking in my
communication skills, but i guess you also don't make things easy.

> Your half-baked proposals may look good from a kernel maintenance
> viewpoint, but in our opinion they have a negative impact on the d-i side
> of the equation.

And have you added stable-security into the equation ? Your choices of back in
april are in part responsible for the abysmal situation in stable-security
with regard to kernels during these past months. Don't look only to save a few
hours of work during the moment, in order to lose huge amounts of times (and
irremediable lose of face even) later on.

> Rejecting a badly thought out proposal is _not_ the same as saying no
> outright.

Yeah, but you have kept saying to me : it is a stupid idea, don't even think
about it, and then you speak about badly thought out proposal ?

> I'm not going to repeat the arguments here. They can be found in the
> archives.

Indeed, apart from the fact that they are the arguments against the wrong
proposal :)

> Your attitude does nothing to motivate me to work on this.

Yep, but i don't ask you to work on this, while you ask me to not work on it
and keep the status quo, which is broken.

Friendly,

Sven Luther



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Joey Hess
In reply to this post by Sven Luther
Sven Luther wrote:
> 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.

Cite message-ids or irc logs please.

> 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 :)

Understanding how the above paragraph could be perceived as insulting is
left as an exersise for the reader.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Joey Hess
In reply to this post by Sven Luther
Sven Luther wrote:
> And have you added stable-security into the equation ? Your choices of back in
> april are in part responsible for the abysmal situation in stable-security
> with regard to kernels during these past months.

Pedantically speaking, fjp made no d-i release decisions last April.

If you would like to blame this pendant, you'll need to be a bit more
specific.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Frans Pop
In reply to this post by Sven Luther
On Tuesday 03 January 2006 23:52, Sven Luther wrote:
> The current proposal is about simply using the same .udeb organisation
> and move it inside the linux-2.6 common package, which is something
> that works out just fine for ubuntu even, but which the current
> linux-2.6 common package infrastructure could also handle.

So, when can we expect a coherent, full proposal (with overview of
benefits, possible pitfalls, things that need to be worked out further,
and so on) on this in a dedicated mail on a new thread to the relevant
mailing lists, so we can actually comment on it instead of only seeing a
rough outline mentioned every so often as part of a flame?

(Without the "current method sucks" comments please; saying "I think the
current situation could be improved by..." is much more likely to get
positive reactions.)

> The only
> reason i saw against this was a mail from joeyh mentioning ease of
> moving modules around inside .udebs, and that this would be easier
> under the d-i umbrella than if it is inside the kernel, and naturally
> the old sarge-time brokeness in the archive infrastructure, which is
> presumably fixed by now, or should be fixed for etch.

You forget the argument that when kernel udebs are maintained within d-i,
we will be much more likely to spot changes in them as a possible cause
of breakage when installation-reports come in.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Joey Hess
On Tue, Jan 03, 2006 at 06:09:18PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > And have you added stable-security into the equation ? Your choices of back in
> > april are in part responsible for the abysmal situation in stable-security
> > with regard to kernels during these past months.
>
> Pedantically speaking, fjp made no d-i release decisions last April.

Nope, you did, and the "Your" above was meant to be the d-i team.

I also remember you accusing of single-handledly delaying the sarge release by
a week, which was not welcome after i invested almost a week fighthing with
k-p to get the 2.4 ppc kernels in a decent shape for sarge, especially as i
didn't really believe into 2.4 powerpc kernels at that time. Would i have told
you at the start of that week what i would have tried to do, can you honestly
you would have let me do it ?

But anyway, let's agree to disagree or whatever, and stop hurting each other,
there will be a proposal made in the 2.6.16 timeframe, and we can then speak
again about this.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Frans Pop
On Wed, Jan 04, 2006 at 12:13:37AM +0100, Frans Pop wrote:

> On Tuesday 03 January 2006 23:52, Sven Luther wrote:
> > The current proposal is about simply using the same .udeb organisation
> > and move it inside the linux-2.6 common package, which is something
> > that works out just fine for ubuntu even, but which the current
> > linux-2.6 common package infrastructure could also handle.
>
> So, when can we expect a coherent, full proposal (with overview of
> benefits, possible pitfalls, things that need to be worked out further,
> and so on) on this in a dedicated mail on a new thread to the relevant
> mailing lists, so we can actually comment on it instead of only seeing a
> rough outline mentioned every so often as part of a flame?

The linux-2.6 package will propose a solution which will produce the *EXACT
SAME* set of .udebs as with the current kernel-wedge solution, and will be
more easy to maintain in a more automated way, and integrated with the rest of
the linux-2.6 kernel, so porters only need to do the work once in a single
integrated way.

> (Without the "current method sucks" comments please; saying "I think the
> current situation could be improved by..." is much more likely to get
> positive reactions.)

This is not my past experience though, and the current method sucks, this is a
fact, i as powerpc porter of d-i have to live with, so why should i not be
allowed to express my opinion about this ?

> > The only
> > reason i saw against this was a mail from joeyh mentioning ease of
> > moving modules around inside .udebs, and that this would be easier
> > under the d-i umbrella than if it is inside the kernel, and naturally
> > the old sarge-time brokeness in the archive infrastructure, which is
> > presumably fixed by now, or should be fixed for etch.
>
> You forget the argument that when kernel udebs are maintained within d-i,
> we will be much more likely to spot changes in them as a possible cause
> of breakage when installation-reports come in.

well, if the only thing you are afraid about is documentation, we shall
provide you with this information in a way most suitable. All this can and and
will be easily automated and presented upon you on a platter, which is not the
case with the current kernel-wedge situation, where the i386 .udebs and
kernel-wedge are updated and the rest of the ports left out in the cold
without any kind of info about possible breakage already fixed on i386, thanks
you very much, so two weights two measures, right ?

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Sven Luther
In reply to this post by Joey Hess
On Tue, Jan 03, 2006 at 06:04:39PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > 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.
>
> Cite message-ids or irc logs please.

Such hiding in the sand, ...  well i don't keep irc logs, and you can go
searching for those past email posts as well as i can.

>
> > 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 :)
>
> Understanding how the above paragraph could be perceived as insulting is
> left as an exersise for the reader.

Yeah, and i have mails from you which where degrees of magnitude more
insulting than those, and i have still not forgiven you about the way you
hurt me in april. So tone done your arrogance a bit, please.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Adam Heath
In reply to this post by Margarita Manterola
On Tue, 3 Jan 2006, Margarita Manterola wrote:

> On 1/3/06, Sven Luther <[hidden email]> wrote:
>
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
> > [...]
> > 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.
> >
> > 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. Already you are considering upgrading the sarge kernel
> > which has some trouble booting on a rather non-negligible quantity of
> > hardware, so having a two version outdated kernel at release time is not nice.
>
> I really don't think that having a four months out-dated kernel is
> that bad.  What is really important is to have stable kernels.  Past
> experience with the modified 2.6 release policy has shown that some
> 2.6 kernels are pretty stable and some others are quite crappy.

Not to mention that 2.6.15 requires a newer udev.  Who knows what other newer
things newer kernels might require.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Jonas Smedegaard
In reply to this post by Sven Luther
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 4 Jan 2006 00:24:04 +0100
Sven Luther <[hidden email]> wrote:

> > (Without the "current method sucks" comments please; saying "I
> > think the current situation could be improved by..." is much more
> > likely to get positive reactions.)
>
> This is not my past experience though, and the current method sucks,
> this is a fact, i as powerpc porter of d-i have to live with, so why
> should i not be allowed to express my opinion about this ?

Because your ignorance of being rude will hurt the conversation - even
if your arguments are sane.


Go ahead and claim that I have no right to say so due to my having a
record of being rude myself. Such reaction would only prove my point
here.


 - Jonas

P.S.

Please do *not* cc me as I am subscribed to d-kernel!

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDuwm8n7DbMsAkQLgRAklqAJ9Tz82+Gw7DjDid2F2cncgsjh2kswCfcZYn
J8jSPC7UpM3ut3Oo/5BXkK4=
=seHD
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: bits from the release team

Marco d'Itri
In reply to this post by Adam Heath
On Jan 04, Adam Heath <[hidden email]> wrote:

> Not to mention that 2.6.15 requires a newer udev.  Who knows what other newer
> things newer kernels might require.
OTOH, old kernel are buggy and out of date wrt modern hardware, and we
lack the manpower to backport for years fixes and new features RHEL-style.
Do you have a better solution?
(Other than telling people "just use Ubuntu", which is what I do.)

--
ciao,
Marco

signature.asc (196 bytes) Download Attachment
123