RFD: Kernel release numbering

RFD: Kernel release numbering

[Linus Torvalds]

This is an idea that has been brewing for some time: Andrew has mentioned
it a couple of times, I've talked to some people about it, and today Davem
sent a suggestion along similar lines to me for 2.6.12.

Namely that we could adopt the even/odd numbering scheme that we used to 
do on a minor number basis, and instead of dropping it entirely like we 
did, we could have just moved it to the release number, as an indication 
of what was the intent of the release.

The problem with major development trees like 2.4.x vs 2.5.x was that the 
release cycles were too long, and that people hated the back- and 
forward-porting. That said, it did serve a purpose - people kind of knew 
where they stood, even though we always ended up having to have big 
changes in the stable tree too, just to keep up with a changing landscape.

So the suggestion on the table would be to go back to even/odd, but do it 
at the "micro-level" of single releases, rather than make it a two- or 
three-year release cycle.

In this setup, all kernels would still be _stable_, in the sense that we
don't anticipate any real breakage (if we end up having to rip up so much
basic stuff that we have to break anything, we'd go back to the 2.7.x kind
of numbering scheme). So we should fear odd releases, but track them, to 
make sure that they are good (if you don't track them, and problems won't 
be fixed in the even version either)

But we'd basically have stricter concerns for an even release, and in
particular the plan would be that the diff files would alternate between
bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
2.6.11->12 release would be a "stability only" thing, and hopefully the
diff file would be much smaller).

We'd still do the -rcX candidates as we go along in either case, so as a 
user you wouldn't even _need_ to know, but the numbering would be a rough 
guide to intentions. Ie I'd expect that distributions would always try to 
base their stuff off a 2.6.<even> release.

It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
kind of even/odd thing didn't _work_, the problems really were an issue of
too big granularity making it hard for user and developers alike. So I see
this as a tweak of the "let's drop the notion althogether for now"  
decision, and just modify it to "even/odd is meaningful at all levels".

In other words, we'd have an increasing level of instability with an odd 
release number, depending on how long-term the instability is.

 - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
   patches leading up to it (timeframe: a week or two)

with the odd numbers going like:

 - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
   to it (timeframe: a month or two).
 - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
   several releases (timeframe: a year or two)
 - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
   the kernel to be a microkernel using a special message-passing version 
   of Visual Basic. (timeframe: "we expect that he will be released from 
   the mental institution in a decade or two").

The reason I put a shorter timeframe on the "all-even" kernel is because I
don't want developers to be too itchy and sitting on stuff for too long if
they did something slightly bigger. In theory, the longer the better
there, but in practice this release numbering is still nothing but a hint
of the _intent_ of the developers - it's still not a guarantee of "we
fixed all bugs", and anybody who expects that (and tries to avoid all odd 
release entirely) is just setting himself up for not testing - and thus 
bugs.

Comments?

		Linus

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

__Stable__ would be a good thing. The entire 2.6 development has been a 
disaster from
a stability viewpoint. I have to maintain a huge tree of patches in 
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even 
number releases will take longer
but it's worth the wait.

Jeff

Linus Torvalds wrote:

>This is an idea that has been brewing for some time: Andrew has mentioned
>it a couple of times, I've talked to some people about it, and today Davem
>sent a suggestion along similar lines to me for 2.6.12.
>
>Namely that we could adopt the even/odd numbering scheme that we used to 
>do on a minor number basis, and instead of dropping it entirely like we 
>did, we could have just moved it to the release number, as an indication 
>of what was the intent of the release.
>
>The problem with major development trees like 2.4.x vs 2.5.x was that the 
>release cycles were too long, and that people hated the back- and 
>forward-porting. That said, it did serve a purpose - people kind of knew 
>where they stood, even though we always ended up having to have big 
>changes in the stable tree too, just to keep up with a changing landscape.
>
>So the suggestion on the table would be to go back to even/odd, but do it 
>at the "micro-level" of single releases, rather than make it a two- or 
>three-year release cycle.
>
>In this setup, all kernels would still be _stable_, in the sense that we
>don't anticipate any real breakage (if we end up having to rip up so much
>basic stuff that we have to break anything, we'd go back to the 2.7.x kind
>of numbering scheme). So we should fear odd releases, but track them, to 
>make sure that they are good (if you don't track them, and problems won't 
>be fixed in the even version either)
>
>But we'd basically have stricter concerns for an even release, and in
>particular the plan would be that the diff files would alternate between
>bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
>2.6.11->12 release would be a "stability only" thing, and hopefully the
>diff file would be much smaller).
>
>We'd still do the -rcX candidates as we go along in either case, so as a 
>user you wouldn't even _need_ to know, but the numbering would be a rough 
>guide to intentions. Ie I'd expect that distributions would always try to 
>base their stuff off a 2.6.<even> release.
>
>It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
>kind of even/odd thing didn't _work_, the problems really were an issue of
>too big granularity making it hard for user and developers alike. So I see
>this as a tweak of the "let's drop the notion althogether for now"  
>decision, and just modify it to "even/odd is meaningful at all levels".
>
>In other words, we'd have an increasing level of instability with an odd 
>release number, depending on how long-term the instability is.
>
> - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
>   patches leading up to it (timeframe: a week or two)
>
>with the odd numbers going like:
>
> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
>   to it (timeframe: a month or two).
> - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
>   several releases (timeframe: a year or two)
> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>   the kernel to be a microkernel using a special message-passing version 
>   of Visual Basic. (timeframe: "we expect that he will be released from 
>   the mental institution in a decade or two").
>
>The reason I put a shorter timeframe on the "all-even" kernel is because I
>don't want developers to be too itchy and sitting on stuff for too long if
>they did something slightly bigger. In theory, the longer the better
>there, but in practice this release numbering is still nothing but a hint
>of the _intent_ of the developers - it's still not a guarantee of "we
>fixed all bugs", and anybody who expects that (and tries to avoid all odd 
>release entirely) is just setting himself up for not testing - and thus 
>bugs.
>
>Comments?
>
>		Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: RFD: Kernel release numbering

[Randy.Dunlap]

Jeff V. Merkey wrote:
> 
> __Stable__ would be a good thing. The entire 2.6 development has been a 
> disaster from
> a stability viewpoint. I have to maintain a huge tree of patches in 
> order to ship appliance
> builds due to the lack of stability for 2.6. I think that the even 
> number releases will take longer but it's worth the wait.
> 
> Jeff

Linus's release cycle estimate might be optimistic.  :)

I'm seeing lots more bug reports recently than I care to see.  :(

> Linus Torvalds wrote:
> 
>> This is an idea that has been brewing for some time: Andrew has mentioned
>> it a couple of times, I've talked to some people about it, and today 
>> Davem
>> sent a suggestion along similar lines to me for 2.6.12.
>>
>> Namely that we could adopt the even/odd numbering scheme that we used 
>> to do on a minor number basis, and instead of dropping it entirely 
>> like we did, we could have just moved it to the release number, as an 
>> indication of what was the intent of the release.
>>
>> The problem with major development trees like 2.4.x vs 2.5.x was that 
>> the release cycles were too long, and that people hated the back- and 
>> forward-porting. That said, it did serve a purpose - people kind of 
>> knew where they stood, even though we always ended up having to have 
>> big changes in the stable tree too, just to keep up with a changing 
>> landscape.
>>
>> So the suggestion on the table would be to go back to even/odd, but do 
>> it at the "micro-level" of single releases, rather than make it a two- 
>> or three-year release cycle.
>>
>> In this setup, all kernels would still be _stable_, in the sense that we
>> don't anticipate any real breakage (if we end up having to rip up so much
>> basic stuff that we have to break anything, we'd go back to the 2.7.x 
>> kind
>> of numbering scheme). So we should fear odd releases, but track them, 
>> to make sure that they are good (if you don't track them, and problems 
>> won't be fixed in the even version either)
>>
>> But we'd basically have stricter concerns for an even release, and in
>> particular the plan would be that the diff files would alternate between
>> bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
>> 2.6.11->12 release would be a "stability only" thing, and hopefully the
>> diff file would be much smaller).
>>
>> We'd still do the -rcX candidates as we go along in either case, so as 
>> a user you wouldn't even _need_ to know, but the numbering would be a 
>> rough guide to intentions. Ie I'd expect that distributions would 
>> always try to base their stuff off a 2.6.<even> release.
>>
>> It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
>> kind of even/odd thing didn't _work_, the problems really were an 
>> issue of
>> too big granularity making it hard for user and developers alike. So I 
>> see
>> this as a tweak of the "let's drop the notion althogether for now"  
>> decision, and just modify it to "even/odd is meaningful at all levels".
>>
>> In other words, we'd have an increasing level of instability with an 
>> odd release number, depending on how long-term the instability is.
>>
>> - 2.6.<even>: even at all levels, aim for having had minimally 
>> intrusive   patches leading up to it (timeframe: a week or two)
>>
>> with the odd numbers going like:
>>
>> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading 
>> up   to it (timeframe: a month or two).
>> - 2.<odd>.x: aim for big changes that may destabilize the kernel for   
>> several releases (timeframe: a year or two)
>> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>>   the kernel to be a microkernel using a special message-passing 
>> version   of Visual Basic. (timeframe: "we expect that he will be 
>> released from   the mental institution in a decade or two").
>>
>> The reason I put a shorter timeframe on the "all-even" kernel is 
>> because I
>> don't want developers to be too itchy and sitting on stuff for too 
>> long if
>> they did something slightly bigger. In theory, the longer the better
>> there, but in practice this release numbering is still nothing but a hint
>> of the _intent_ of the developers - it's still not a guarantee of "we
>> fixed all bugs", and anybody who expects that (and tries to avoid all 
>> odd release entirely) is just setting himself up for not testing - and 
>> thus bugs.
>>
>> Comments?


-- 
~Randy

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

Randy.Dunlap wrote:

> Jeff V. Merkey wrote:
>
>>
>> __Stable__ would be a good thing. The entire 2.6 development has been 
>> a disaster from
>> a stability viewpoint. I have to maintain a huge tree of patches in 
>> order to ship appliance
>> builds due to the lack of stability for 2.6. I think that the even 
>> number releases will take longer but it's worth the wait.
>>
>> Jeff
>
>
> Linus's release cycle estimate might be optimistic.  :)
>
Yep, but at least he is addressing the issue and taking responsibility 
and showing good prudent leadership and some
reasonable and sound ideas to correct it. 

> I'm seeing lots more bug reports recently than I care to see.  :(


Yep.

Jeff

Re: RFD: Kernel release numbering

[Zwane Mwaikambo]

On Wed, 2 Mar 2005, Jeff V. Merkey wrote:

> __Stable__ would be a good thing. The entire 2.6 development has been a 
> disaster from a stability viewpoint. I have to maintain a huge tree of 
> patches in order to ship appliance builds due to the lack of stability 
> for 2.6. I think that the even number releases will take longer but it's 
> worth the wait.

What form of instability are you referring to?

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

Zwane Mwaikambo wrote:

>On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
>
>  
>
>>__Stable__ would be a good thing. The entire 2.6 development has been a 
>>disaster from a stability viewpoint. I have to maintain a huge tree of 
>>patches in order to ship appliance builds due to the lack of stability 
>>for 2.6. I think that the even number releases will take longer but it's 
>>worth the wait.
>>    
>>
>
>What form of instability are you referring to?
>
>  
>
Where have you been? Read the bug reports and the types of bugs.

Jeff

Re: RFD: Kernel release numbering

[Wakko Warner]

I'm only emailing to the list, feel free to keep my in CC (this way I'll
know what part of the thread was directed towards me)

Jeff V. Merkey wrote:
> __Stable__ would be a good thing. The entire 2.6 development has been a 
> disaster from
> a stability viewpoint. I have to maintain a huge tree of patches in 
> order to ship appliance
> builds due to the lack of stability for 2.6. I think that the even 
> number releases will take longer
> but it's worth the wait.

I agree about the stability of the 2.6 kernels.  The system I'm using now
has always been 2.6 since I first installed it.  I have noticed there were
stability issues with 2.6.  I remember 2.6.7 was fairly good and was a bit
stable.  2.6.8.1 wasn't that stable (I'm sure I had the .1 patch on it,
however, attempting to do a lock over NFS caused the system to hard freeze).
2.6.9 was more unstable especially with USB.  2.6.10 (which I'm using now)
has to be IMO the most stable 2.6 kernel produced.  I'm quite pleased with
it (and to all the kernel hackers, thanks for a great kernel).

P.S.  System is a dual xeon 2.6ghz on a supermicro x5da8 1gb ram.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: RFD: Kernel release numbering

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Wed, 02 Mar 2005 15:53:36 MST, "Jeff V. Merkey" said:
> __Stable__ would be a good thing. The entire 2.6 development has been a 
> disaster from
> a stability viewpoint. I have to maintain a huge tree of patches in 
> order to ship appliance
> builds due to the lack of stability for 2.6. I think that the even 
> number releases will take longer
> but it's worth the wait.

Remember - each patch you successfully push upstream is one less patch
you have to maintain.  So re-read Documentation/SubmittingPatches, beat
the patches into shape, and send them on their way. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: RFD: Kernel release numbering

[Dmitry Torokhov]

On Wed, 2 Mar 2005 14:21:38 -0800 (PST), Linus Torvalds
<torvalds@osdl.org> wrote:
> 
> Comments?
> 

Just rename:

2.<even>.<odd>-rcX  ->  2.<even>.y-preX
2.<even>.<odd>      ->  2.<even>.y-rcX
2.<even>.<even>     ->  2.<even>.y

-- 
Dmitry

Re: RFD: Kernel release numbering

[Lars Marowsky-Bree]

On 2005-03-02T14:21:38, Linus Torvalds <torvalds@osdl.org> wrote:

> We'd still do the -rcX candidates as we go along in either case, so as a 
> user you wouldn't even _need_ to know, but the numbering would be a rough 
> guide to intentions. Ie I'd expect that distributions would always try to 
> base their stuff off a 2.6.<even> release.

If the users wouldn't even have to know, why do it? Who will benefit
from this, then?

I think a better approach, and one which is already working out well in
practice, is to put "more intrusive" features into -mm first, and only
migrate them into 2.6.x when they have 'stabilized'.

This could be improved: _All_ new features have to go through -mm first
for a period (of whatever length) / one cycle. 2.6.x only directly picks
up "obvious" bugfixes, and a select set of features which have ripened
in -mm. 2.6.x-pre releases would then basically "only" clean up
integration bugs.

-mm would be the 'feature tree'. Of course, features which have matured
in other eligible trees might also work; the key point is the two-stage
approach and it doesn't matter whether the chaos stage has one or three
trees, as long as it's not more than that.

I think that would be natural extension of how things already work and
just tightens the process some.


(From a vendor perspective, this would mean we'd be safe picking up any
2.6.x tree + select choices from x+1-pre plus whatever we are force fed
by those who pay.)

If one wanted to get fancy, which I'm throwing in just to make everybody
lose the core point of the argument: One could associate "points" with
each feature / patch in -mm, based on an estimation of how
intrusive/well-tested/dangerous/heavenly that patch is, and mandate that
only 42 points per 2.6.x release are allowed.

Of course, one could also apply common sense. But, that's not as silly.
Or way more so, but less amusing than voting wars.

> Comments?

The numbering scheme is more confusing and unclear, and complexity is
the enemy of reliability.



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

Re: RFD: Kernel release numbering

[Greg KH]

On Wed, Mar 02, 2005 at 11:58:46PM +0100, Lars Marowsky-Bree wrote:
> 
> This could be improved: _All_ new features have to go through -mm first
> for a period (of whatever length) / one cycle. 2.6.x only directly picks
> up "obvious" bugfixes, and a select set of features which have ripened
> in -mm. 2.6.x-pre releases would then basically "only" clean up
> integration bugs.

This is the way things work today already.  The only exception being the
networking code, but hey, networking's always been special :)

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Lars Marowsky-Bree]

On 2005-03-02T15:23:49, Greg KH <greg@kroah.com> wrote:

> > This could be improved: _All_ new features have to go through -mm first
> > for a period (of whatever length) / one cycle. 2.6.x only directly picks
> > up "obvious" bugfixes, and a select set of features which have ripened
> > in -mm. 2.6.x-pre releases would then basically "only" clean up
> > integration bugs.
> 
> This is the way things work today already.  The only exception being the
> networking code, but hey, networking's always been special :)

That's exactly what I'm saying. It already works this way, w/o
misleading the users and attaching confusing meaning to minor revision
numbers. It could do with being more clearly advertised and sticked to,
but that's about it.

Don't confuse more. People are already way to confused on their own.

If anything, if we expect a release to have ... interesting
side-effects, Linus will find just the funny words for the release notes
to say so ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

Re: RFD: Kernel release numbering

[Zwane Mwaikambo]

On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:

> On 2005-03-02T14:21:38, Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > We'd still do the -rcX candidates as we go along in either case, so as a 
> > user you wouldn't even _need_ to know, but the numbering would be a rough 
> > guide to intentions. Ie I'd expect that distributions would always try to 
> > base their stuff off a 2.6.<even> release.
> 
> If the users wouldn't even have to know, why do it? Who will benefit
> from this, then?
> 
> I think a better approach, and one which is already working out well in
> practice, is to put "more intrusive" features into -mm first, and only
> migrate them into 2.6.x when they have 'stabilized'.
> 
> This could be improved: _All_ new features have to go through -mm first
> for a period (of whatever length) / one cycle. 2.6.x only directly picks
> up "obvious" bugfixes, and a select set of features which have ripened
> in -mm. 2.6.x-pre releases would then basically "only" clean up
> integration bugs.
> 
> -mm would be the 'feature tree'. Of course, features which have matured
> in other eligible trees might also work; the key point is the two-stage
> approach and it doesn't matter whether the chaos stage has one or three
> trees, as long as it's not more than that.

Certainly -mm can be the feature tree, but i've noticed that not that many 
people run -mm aside from developers. Meaning that a fair number of bugs 
seep into Linus' tree before they get attended to. It would even be more 
effective if we could get more -mm user coverage. A Linus based odd number 
might be closer to that if we hope on people unwittingly running them.

Re: RFD: Kernel release numbering

[Neil Brown]

On Wednesday March 2, zwane@arm.linux.org.uk wrote:
>                                                   A Linus based odd number 
> might be closer to that if we hope on people unwittingly running them.
                                               ^^^^^^^^^^^

I think this is a very unhelpful attitude.  Don't expect people to do
things unwittingly.  It won't work.

You should expect people to be more intelligent and more confused than
you expect (yes, I know that is recursive).

Being more intelligent means you won't be able to trick them.
Being more confused means they will try out less things.

Constantly changing the naming will confuse people, and they will
experiment less.
Having some clear and often-stated gaols for different releases -
which are adhered to - will make people feel less confused and so more
willing to experiment.  Asking nicely probably helps too.

--e.g.--
The latest 2.6.X is stable. Feel free to use it for any system.
The latest 2.6.X-pre is fairly stable.  Please consider using it on
     non-"mission critical" system.
The latest 2.6.X-mmY is under development. Please test it if you have
     the opportunity.


Agree on that.  Stick to it.  Get everyone to plaster it on their
websites.  Stick it at the bottom of all @vger.kernel.org mailing
lists. See what happens.

NeilBrown

Re: RFD: Kernel release numbering

[Zwane Mwaikambo]

On Thu, 3 Mar 2005, Neil Brown wrote:

> On Wednesday March 2, zwane@arm.linux.org.uk wrote:
> >                                                   A Linus based odd number 
> > might be closer to that if we hope on people unwittingly running them.
>                                                ^^^^^^^^^^^
> 
> I think this is a very unhelpful attitude.  Don't expect people to do
> things unwittingly.  It won't work.

I think you may be reading too much into that, by unwittingly i meant that 
people tend to run Linus' releases more than others because they are 
considered to be more stable.

Thanks,
	Zwane

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:
> 
> If the users wouldn't even have to know, why do it? Who will benefit
> from this, then?

They don't _have_ to know. But both users and developers can take 
advantage of this to time their patches.

> I think a better approach, and one which is already working out well in
> practice, is to put "more intrusive" features into -mm first, and only
> migrate them into 2.6.x when they have 'stabilized'.

That wouldn't change. But we still have the issue of "they have to be 
released sometime". This makes it clear to everybody when to merge, and 
when to calm down.

		Linus

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 03:44:58PM -0800, Linus Torvalds wrote:

 > > I think a better approach, and one which is already working out well in
 > > practice, is to put "more intrusive" features into -mm first, and only
 > > migrate them into 2.6.x when they have 'stabilized'.
 > 
 > That wouldn't change. But we still have the issue of "they have to be 
 > released sometime". This makes it clear to everybody when to merge, and 
 > when to calm down.

So is the problem that people aren't listening when you say "lets slow down" ?
Why would this change things for people who obviously ignore what you say ? :)

I'll bet you'll still get flooded with "lets see if Linus takes this despite
what he said in his last announcement" patches if we moved to this model.

The only thing that would make a difference afaics, would be you putting
your foot down and just ignoring such submissions ?

		Dave

Re: RFD: Kernel release numbering

[Alan Cox]

On Iau, 2005-03-03 at 00:32, Dave Jones wrote:
> On Wed, Mar 02, 2005 at 03:44:58PM -0800, Linus Torvalds wrote:
> The only thing that would make a difference afaics, would be you putting
> your foot down and just ignoring such submissions ?

ROTFL. You've not watched Linus for a long time have you. I could
mention 2.1.102, 1.3.59 and a few other "just ready for release so I
added this cool..." cases 8)

Re: RFD: Kernel release numbering

[Andrew Morton]

Linus Torvalds <torvalds@osdl.org> wrote:
>
> The reason I put a shorter timeframe on the "all-even" kernel is because I
> don't want developers to be too itchy and sitting on stuff for too long if
> they did something slightly bigger.

If they're feeling itchy they should dig in and help fix the bugs in 2.6.<odd>.

Re: RFD: Kernel release numbering

[Randy.Dunlap]

Andrew Morton wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
>>The reason I put a shorter timeframe on the "all-even" kernel is because I
>>don't want developers to be too itchy and sitting on stuff for too long if
>>they did something slightly bigger.
> 
> 
> If they're feeling itchy they should dig in and help fix the bugs in 2.6.<odd>.

Yep, that's what I'll be doing.  :)

-- 
~Randy

Re: RFD: Kernel release numbering

[Greg KH]

/me kills my patchbomb script for now

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> 
>  - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
>    patches leading up to it (timeframe: a week or two)
> 
> with the odd numbers going like:
> 
>  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
>    to it (timeframe: a month or two).

Ok, that's acceptable to me, but realize that this puts a bigger burden
on the maintainers to queue up patches for you.  It's not that big of a
deal, just something to be aware of.

Speaking of which, does this mean I shouldn't hit you with all of my
pending stuff?  I know some of the other subsystem maintainers have a
lot of stuff queued up too.  Should we start this new numbering scheme
as of today?  Or wait until 2.6.13?

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Willy Tarreau]

Hi Greg,

On Wed, Mar 02, 2005 at 03:04:01PM -0800, Greg KH wrote:
> /me kills my patchbomb script for now
> 
> On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> > 
> >  - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
> >    patches leading up to it (timeframe: a week or two)
> > 
> > with the odd numbers going like:
> > 
> >  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
> >    to it (timeframe: a month or two).
> 
> Ok, that's acceptable to me, but realize that this puts a bigger burden
> on the maintainers to queue up patches for you.  It's not that big of a
> deal, just something to be aware of.

Not necessaruly, because the rules could be more relaxed during -rc stage
in an odd release, and stable releases could be shorter, so at the end, the
"patch fridge" would be needed only between the very end of the odd version
and the start of the even one.

Another possibility is for developpers to start to submit/merge patches for
the next odd release while the even one is still in -rc.

> Speaking of which, does this mean I shouldn't hit you with all of my
> pending stuff?  I know some of the other subsystem maintainers have a
> lot of stuff queued up too.  Should we start this new numbering scheme
> as of today?  Or wait until 2.6.13?

if there is so much pending stuff, why not sacrifice 2.6.12, use 2.6.13
to fix a bit and merge even more, then 2.6.14 would be the real first
stable release ?

Regards,
Willy

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 12:34:59AM +0100, Willy Tarreau wrote:
> On Wed, Mar 02, 2005 at 03:04:01PM -0800, Greg KH wrote:
> > /me kills my patchbomb script for now
> > 
> > On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> > > 
> > >  - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
> > >    patches leading up to it (timeframe: a week or two)
> > > 
> > > with the odd numbers going like:
> > > 
> > >  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
> > >    to it (timeframe: a month or two).
> > 
> > Ok, that's acceptable to me, but realize that this puts a bigger burden
> > on the maintainers to queue up patches for you.  It's not that big of a
> > deal, just something to be aware of.
> 
> Not necessaruly, because the rules could be more relaxed during -rc stage
> in an odd release, and stable releases could be shorter, so at the end, the
> "patch fridge" would be needed only between the very end of the odd version
> and the start of the even one.

It's still a lot of work to queue up pending patches.  Over a certian
limit, it gets pretty unstable, trust me.  I'm not complaining, just
letting you know that this will push more work on the maintainers, but
hey, we scale, so it's not that big of a deal :)

> Another possibility is for developpers to start to submit/merge patches for
> the next odd release while the even one is still in -rc.

No, that's not ok to do.  We want people to focus on getting a -rc out.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
 > 
 > This is an idea that has been brewing for some time: Andrew has mentioned
 > it a couple of times, I've talked to some people about it, and today Davem
 > sent a suggestion along similar lines to me for 2.6.12.
 > 
 > Namely that we could adopt the even/odd numbering scheme that we used to 
 > do on a minor number basis, and instead of dropping it entirely like we 
 > did, we could have just moved it to the release number, as an indication 
 > of what was the intent of the release.

Random ideas.  Why not use the already established 2.6.x.y method ? 
This allows development to continue on 2.6.x+1, and if needed, you
should be able to bk pull the 2.6.x.y[n] tree(s) into 2.6.x+1 no ?

My concern about this 'stable kernel every other release' method is
that if a particular development cycle drags on for some reason,
and certain bugs never got fixed in the previous release,
that's a long time users have to wait until they get things fixed.

It's somewhat akin to the problem with the infrequent out-of-tree merges
that some subsystem maintainers have. If the latest push they do
doesn't fix your bug, you typically have to wait until the next
release until they do another push.

		Dave

Re: RFD: Kernel release numbering

[Russell King]

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> In other words, we'd have an increasing level of instability with an odd 
> release number, depending on how long-term the instability is.
> 
>  - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
>    patches leading up to it (timeframe: a week or two)
> 
> with the odd numbers going like:
> 
>  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
>    to it (timeframe: a month or two).
>  - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
>    several releases (timeframe: a year or two)
>  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>    the kernel to be a microkernel using a special message-passing version 
>    of Visual Basic. (timeframe: "we expect that he will be released from 
>    the mental institution in a decade or two").

This sounds good, until you realise that some of us have been sitting
on about 30 patches for at least the last month, because we where
following your guidelines about the -rc's.  Things like adding support
for new ARM machines and other devices, dynamic tick support for ARM,
etc.

If I'm going to have to sit on this stuff for another month, it'll bit
rot rather badly, and I might as well throw away all these patches now
and ask people not to send stuff other than pure bug fixes.

A slightly bigger problem is that I'm in the middle of merging a large
chunk of these for you right now, and at least Andrew has already pulled
some of these from my BK repo.

If we are going to do this, can we start it post 2.6.12 please?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 11:06:34PM +0000, Russell King wrote:
 > On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
 > > In other words, we'd have an increasing level of instability with an odd 
 > > release number, depending on how long-term the instability is.
 > > 
 > >  - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
 > >    patches leading up to it (timeframe: a week or two)
 > > 
 > > with the odd numbers going like:
 > > 
 > >  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
 > >    to it (timeframe: a month or two).
 > >  - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
 > >    several releases (timeframe: a year or two)
 > >  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
 > >    the kernel to be a microkernel using a special message-passing version 
 > >    of Visual Basic. (timeframe: "we expect that he will be released from 
 > >    the mental institution in a decade or two").
 > 
 > This sounds good, until you realise that some of us have been sitting
 > on about 30 patches for at least the last month, because we where
 > following your guidelines about the -rc's.  Things like adding support
 > for new ARM machines and other devices, dynamic tick support for ARM,
 > etc.
 > 
 > If I'm going to have to sit on this stuff for another month, it'll bit
 > rot rather badly, and I might as well throw away all these patches now
 > and ask people not to send stuff other than pure bug fixes.

The fact that this new approach serialises the stable/devel lineation
whereas traditionally it was parallel (2.x.y/2.x+1.y) is going to be
a real pain for a lot of maintainers.

In short, instead of a single 'merge with linus tree', I'm now going to
need a 'merge with linus' and 'merge with linus next time' tree for every
tree I maintain.. It's not impossible to maintain, but its extra burden.
Burden which a lot of folks may consider not worth it.

		Dave

Re: RFD: Kernel release numbering

[Jeff Garzik]

Russell King wrote:
> This sounds good, until you realise that some of us have been sitting
> on about 30 patches for at least the last month, because we where
> following your guidelines about the -rc's.  Things like adding support
> for new ARM machines and other devices, dynamic tick support for ARM,
> etc.

30?  Try 310 changesets, in my netdev-2.6 pending queue.

	Jeff

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Wed, 2 Mar 2005, Jeff Garzik wrote:
> 
> 30?  Try 310 changesets, in my netdev-2.6 pending queue.

Note that I don't think a 2.6.<even> would have problems with things like 
driver updates.

This was somewhat brought on (at least for me, dunno about Davem) by 
things like 4-level page tables etc stuff. I don't think most people even 
realized how _smoothly_ that thing seems to have gone, even if the ppc64 
people ended up having some really nasty debugging (and they came through 
with flying colors, but they probably didn't much enjoy the thing).

I would not keep regular driver updates from a 2.6.<even> thing. But I 
_would_ try to keep things like all the TSO pain, the 4-level page tables, 
and in general big merges that have been in CVS trees etc, and can't claim 
to be "lots of small stuff".

For example, there's some fundamental 16-bit PCMCIA cleanups pending in
the -mm tree, meaning that the kernel can work with PCMCIA cards without a
"cardmgr" deamon. That would be something that is _not_ appropriate in the
first stable version. That doesn't mean that individual PCMCIA device 
drivers could not get updated.

But hey, you may be right. It might just not be obvious enough which class 
any particular merge falls under.

		Linus

Re: RFD: Kernel release numbering

[Greg KH]

On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
> 
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> > 
> > 30?  Try 310 changesets, in my netdev-2.6 pending queue.
> 
> Note that I don't think a 2.6.<even> would have problems with things like 
> driver updates.
> 
> This was somewhat brought on (at least for me, dunno about Davem) by 
> things like 4-level page tables etc stuff. I don't think most people even 
> realized how _smoothly_ that thing seems to have gone, even if the ppc64 
> people ended up having some really nasty debugging (and they came through 
> with flying colors, but they probably didn't much enjoy the thing).

I think this statement proves that the current development situation is
working quite well.  The nasty breakage and details got worked out in
the -mm tree, and then flowed into your tree when they seemed sane.

> I would not keep regular driver updates from a 2.6.<even> thing. But I 
> _would_ try to keep things like all the TSO pain, the 4-level page tables, 
> and in general big merges that have been in CVS trees etc, and can't claim 
> to be "lots of small stuff".

So, any driver stuff is just fine?  Great, I don't have an issue with
your proposal then, as it wouldn't affect me that much :)

I do understand what you are trying to achieve here, people don't really
test the -rc releases as much as a "real" 2.6.11 release.  Getting a
week of testing and bugfix only type patches to then release a 2.6.12
makes a lot of sense.  For example, see all of the bug reports that came
out of the woodwork today on lkml from the 2.6.11 release...

But accepting 310 netdev patches, 250 USB, 50 PCI, 50 I2c, and 100 ALSA
patches in one week and expect the tree to stay "stable" might be a
pretty unreasonable thing to wish for...

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Wed, 2 Mar 2005, Greg KH wrote:
> 
> I think this statement proves that the current development situation is
> working quite well.  The nasty breakage and details got worked out in
> the -mm tree, and then flowed into your tree when they seemed sane.

Actually, the breakage I was talking about got fixed in _my_ tree.

I'd love for the -mm tree to get more testing, but it doesn't. 

> So, any driver stuff is just fine?  Great, I don't have an issue with
> your proposal then, as it wouldn't affect me that much :)

I don't know about "any", but yeah.

> I do understand what you are trying to achieve here, people don't really
> test the -rc releases as much as a "real" 2.6.11 release.  Getting a
> week of testing and bugfix only type patches to then release a 2.6.12
> makes a lot of sense.  For example, see all of the bug reports that came
> out of the woodwork today on lkml from the 2.6.11 release...

A large part of it is psychological. On the other hand, it may be that
Neil is right and it would just mean that people wouldn't even test the
odd releases (..because they want to wait a couple of weeks for the even
one), so it may not actually end up helping much.

The thing is, I _do_ believe the current setup is working reasonably well.  
But I also do know that some people (a fairly small group, but anyway)  
seem to want an extra level of stability - although those people seem to
not talk so much about "it works" kind of stability, but literally a "we
can't keep up" kind of stability (ie at least a noticeable percentage of
that group is not complaining about crashes, they are complaining about
speed of development).

And I suspect that _anything_ I do won't make those people happy.

		Linus

Re: RFD: Kernel release numbering

[Gene Heskett]

On Wednesday 02 March 2005 20:15, Linus Torvalds wrote:
>On Wed, 2 Mar 2005, Greg KH wrote:
>> I think this statement proves that the current development
>> situation is working quite well.  The nasty breakage and details
>> got worked out in the -mm tree, and then flowed into your tree
>> when they seemed sane.
>
>Actually, the breakage I was talking about got fixed in _my_ tree.
>
>I'd love for the -mm tree to get more testing, but it doesn't.
>
Well, that might change if, when I came crying to the list about 
something thats broken in an -mm release, I wasn't chased off to go 
run a "more stable" release.  Thats occured 2-3 times in the past 
year.

I'll willingly play the canary as long as I don't wind up with a 
totally hosed filesystem.  So far, knock on wood, I've been fairly 
lucky and have not had to do a bare metal recovery from amanda.

>> So, any driver stuff is just fine?  Great, I don't have an issue
>> with your proposal then, as it wouldn't affect me that much :)
>
>I don't know about "any", but yeah.
>
>> I do understand what you are trying to achieve here, people don't
>> really test the -rc releases as much as a "real" 2.6.11 release. 
>> Getting a week of testing and bugfix only type patches to then
>> release a 2.6.12 makes a lot of sense.  For example, see all of
>> the bug reports that came out of the woodwork today on lkml from
>> the 2.6.11 release...
>
>A large part of it is psychological. On the other hand, it may be
> that Neil is right and it would just mean that people wouldn't even
> test the odd releases (..because they want to wait a couple of
> weeks for the even one), so it may not actually end up helping
> much.
>
>The thing is, I _do_ believe the current setup is working reasonably
> well. But I also do know that some people (a fairly small group,
> but anyway) seem to want an extra level of stability - although
> those people seem to not talk so much about "it works" kind of
> stability, but literally a "we can't keep up" kind of stability (ie
> at least a noticeable percentage of that group is not complaining
> about crashes, they are complaining about speed of development).
>
>And I suspect that _anything_ I do won't make those people happy.
>
>		Linus
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: RFD: Kernel release numbering

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

Gene Heskett schrieb:
> On Wednesday 02 March 2005 20:15, Linus Torvalds wrote:
>
>>On Wed, 2 Mar 2005, Greg KH wrote:
>>
>>>I think this statement proves that the current development
>>>situation is working quite well.  The nasty breakage and details
>>>got worked out in the -mm tree, and then flowed into your tree
>>>when they seemed sane.
>>
>>Actually, the breakage I was talking about got fixed in _my_ tree.
>>
>>I'd love for the -mm tree to get more testing, but it doesn't.
>>
>
> Well, that might change if, when I came crying to the list about
> something thats broken in an -mm release, I wasn't chased off to go
> run a "more stable" release.  Thats occured 2-3 times in the past
> year.


A gentoo view: There are lots of patchsets floating around in the gentoo forum
based on either vanilla or mm-kernel, but over the months something has
changed: Previously most patchsets were based on mm, but now are based on
vanilla. Why? Very simple: mm became too unstable. I used to go with a mm
based kernel just for fun, but it changed as one kernel had some serious
issues with reiserfs - and it is really not fun to lose data. (At least I read
about it, before testing that kernel.) Since then i never touched a mm-kernel
again, in fact now I even feel scared to put on a vanilla-rc kernel. I do it,
but I feel like when I use a "stable" mm-kernel from earlier times...

So if you wantpeople to test kernels, they shouldn't be too unstable...

And if you want bug reports, make it easier for the user. I know there is a
txt file in the kernel src dir, but it would be better, if there would be a
complete script which gets all possible need infos itself. Then user driven
input could be minimized.

Furthermore many users are simple afraid to post to lkml. (They report to
forums, but don't want to report to lkml.) Even I often tend to think: Ok, I
came across a small bug. Should I post it or should I wait till next rc?
Usually I wait, because I feel like getting on people's nerves when I post
every little tidbit. Esp if bugreports seem to get ignored motivation goes
down to report again...

Nevertheless, for a fun loving desktop user, I enjoy the pace the linux kernel
is evolving. It was so "boring" the 2.4 days. But on the other hand linux
kernel now tends to break various things with each release. I think esp nvidia
users now about it...

Cheers

--
Prakash Punnoor

formerly known as Prakash K. Cheemplavam

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFD: Kernel release numbering

[Paolo Ciarrocchi]

On Thu, 03 Mar 2005 11:29:07 +0100, Prakash Punnoor <prakashp@arcor.de> wrote:
[...]
> And if you want bug reports, make it easier for the user. I know there is a
> txt file in the kernel src dir, but it would be better, if there would be a
> complete script which gets all possible need infos itself. Then user driven
> input could be minimized.

Yup, having an interactive script that produce a bug-report-date.txt
file would be great.
Furthemore I don't understand why bugzilla is not used  as the main
bug reporting tool.

> Furthermore many users are simple afraid to post to lkml. (They report to
> forums, but don't want to report to lkml.) Even I often tend to think: Ok, I
> came across a small bug. Should I post it or should I wait till next rc?
> Usually I wait, because I feel like getting on people's nerves when I post
> every little tidbit. Esp if bugreports seem to get ignored motivation goes
> down to report again...
> 
> Nevertheless, for a fun loving desktop user, I enjoy the pace the linux kernel
> is evolving. It was so "boring" the 2.4 days. But on the other hand linux
> kernel now tends to break various things with each release. I think esp nvidia
> users now about it...

Nvidia binary driver is a totaly different problem.
 
-- 
Paolo <paolo dot ciarrocchi at gmail dot com>
msn: paolo407@hotmail.com
hello: ciarrop
paoloc.blogspot.com

Re: RFD: Kernel release numbering

[Lee Revell]

On Thu, 2005-03-03 at 11:29 +0100, Prakash Punnoor wrote:
> A gentoo view: There are lots of patchsets floating around in the gentoo forum
> based on either vanilla or mm-kernel, but over the months something has
> changed: Previously most patchsets were based on mm, but now are based on
> vanilla. Why? Very simple: mm became too unstable. I used to go with a mm
> based kernel just for fun, but it changed as one kernel had some serious
> issues with reiserfs - and it is really not fun to lose data. (At least I read
> about it, before testing that kernel.) Since then i never touched a mm-kernel
> again, in fact now I even feel scared to put on a vanilla-rc kernel. I do it,
> but I feel like when I use a "stable" mm-kernel from earlier times...
> 
> So if you wantpeople to test kernels, they shouldn't be too unstable...

Thanks, it's about time someone said this.

We had a preview of what it would be like if "more users tested -mm"
when Ingo's realtime preempt patches were based on it, so the audio
oriented distros briefly shipped -mm kernels.

It was a nightmare.  Most people (icluding myself) experienced daily
lockups.  When Ingo rebased the RT patch against mainline there was
muich rejoicing on LAU.

-mm is just too unstable for anyone but kernel hackers to run.  Anyone
who tells you otherwise is smoking something.

Lee

Re: RFD: Kernel release numbering

[Willy Tarreau]

On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds wrote:
> On Wed, 2 Mar 2005, Greg KH wrote:
> > I do understand what you are trying to achieve here, people don't really
> > test the -rc releases as much as a "real" 2.6.11 release.  Getting a
> > week of testing and bugfix only type patches to then release a 2.6.12
> > makes a lot of sense.  For example, see all of the bug reports that came
> > out of the woodwork today on lkml from the 2.6.11 release...
> 
> A large part of it is psychological. On the other hand, it may be that
> Neil is right and it would just mean that people wouldn't even test the
> odd releases (..because they want to wait a couple of weeks for the even
> one), so it may not actually end up helping much.

It's not the same thing to test ONE release and test SEVERAL -rc. I take
my case as an example. I don't have enough time to keep up, so I try to
compile at least each release and test them on one of my systems, maybe
for curiosity. I would like to test the -rc, but the problem is that you
don't know how much you can expect this or that -rc to be close to usable.
You even expect it to fail or not build at all, so when you don't have much
time to spend on this, unfortunately, you don't test them.

On the contrary, Marcelo makes a strong difference between -pre and -rc.
And when I see a 2.4-rc, I expect it to be a potential candidate, so I
try to get some time to compile it just in case I would discover an awful
bug, and avoid the 2.6.8 -> 2.6.8.1 situation. Honnestly, I would have
reported the 2.6.8 NFS bug earlier if there had been a true -rc before
it (=one which does not change except for trivial bug fixes).

> The thing is, I _do_ believe the current setup is working reasonably well.  
> But I also do know that some people (a fairly small group, but anyway)  
> seem to want an extra level of stability - although those people seem to
> not talk so much about "it works" kind of stability, but literally a "we
> can't keep up" kind of stability (ie at least a noticeable percentage of
> that group is not complaining about crashes, they are complaining about
> speed of development).
> 
> And I suspect that _anything_ I do won't make those people happy.

The only solution against this is to freeze for real and start the devel
tree in parallel. People are not complaining anymore about 2.4 change
speed, because every time a folk sends something, we tell him to push
that into 2.6 and not 2.4. The same thing must work with 2.6 and 2.7.
In the end, there would a general feeling that "2.6 was not as stable
as 2.8", etc... That's not a problem, there are always ups and downs
in software.

Regards,
Willy

Re: RFD: Kernel release numbering

[Greg KH]

On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds wrote:
> The thing is, I _do_ believe the current setup is working reasonably well.  
> But I also do know that some people (a fairly small group, but anyway)  
> seem to want an extra level of stability - although those people seem to
> not talk so much about "it works" kind of stability, but literally a "we
> can't keep up" kind of stability (ie at least a noticeable percentage of
> that group is not complaining about crashes, they are complaining about
> speed of development).
> 
> And I suspect that _anything_ I do won't make those people happy.

That single sentence sums it up perfectly.  When I have given talks
about how our current development cycle works, and what's happening with
it, people just feel odd seeing all of this change happen and get upset
at it.  Perhaps it's because they never paid attention before, or that
they are new to Linux and like to believe that old-style development
models were somehow "better", and that they know we are doing something
wrong.

But when pressed about the issue of speed of development, rate of
change, feature increase, driver updates, and so on, no one else has any
clue of what to do.  They respond with, "but only put bugfixes into a
stable release."  My comeback is explaining how we handle lots of
different types of bugfixes, by api changes, real fixes, and driver
updates for new hardware.  Sometimes these cause other bugs to happen,
or just get shaken out where they were previously hiding (acpi is a
great example of this issue.)  In the end, they usually fall back on
muttering, "well, I'm just glad that I'm not a kernel developer..." and
back away.

Like I previously said, I think we're doing a great job.  The current
-mm staging area could use some more testers to help weed out the real
issues, and we could do "real" releases a bit faster than every 2 months
or so.  But other than that, we have adapted over the years to handle
this extremely high rate of change in a pretty sane manner.

So don't spend too much time worring that we need to make those types of
people happy.  As Jeff said, no other OS is accepting changes at such a
high rate.  But then again, no other OS supports more devices, on more
different processors.  So we must be doing something right :)

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Jeff Garzik]

Greg KH wrote:
> On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds wrote:
> 
>>The thing is, I _do_ believe the current setup is working reasonably well.  
>>But I also do know that some people (a fairly small group, but anyway)  
>>seem to want an extra level of stability - although those people seem to
>>not talk so much about "it works" kind of stability, but literally a "we
>>can't keep up" kind of stability (ie at least a noticeable percentage of
>>that group is not complaining about crashes, they are complaining about
>>speed of development).
>>
>>And I suspect that _anything_ I do won't make those people happy.
> 
> 
> That single sentence sums it up perfectly.  When I have given talks
> about how our current development cycle works, and what's happening with
> it, people just feel odd seeing all of this change happen and get upset
> at it.  Perhaps it's because they never paid attention before, or that
> they are new to Linux and like to believe that old-style development
> models were somehow "better", and that they know we are doing something
> wrong.
> 
> But when pressed about the issue of speed of development, rate of
> change, feature increase, driver updates, and so on, no one else has any
> clue of what to do.  They respond with, "but only put bugfixes into a
> stable release."  My comeback is explaining how we handle lots of
> different types of bugfixes, by api changes, real fixes, and driver
> updates for new hardware.  Sometimes these cause other bugs to happen,
> or just get shaken out where they were previously hiding (acpi is a
> great example of this issue.)  In the end, they usually fall back on
> muttering, "well, I'm just glad that I'm not a kernel developer..." and
> back away.

The pertinent question for a point release (2.6.X.Y) would simply be 
"does a 2.6.11 user really need this fix?"


> Like I previously said, I think we're doing a great job.  The current
> -mm staging area could use some more testers to help weed out the real
> issues, and we could do "real" releases a bit faster than every 2 months
> or so.  But other than that, we have adapted over the years to handle
> this extremely high rate of change in a pretty sane manner.

I think Linus's "even/odd" proposal is an admission that 2.6.X releases 
need some important fixes after it hits kernel.org.

Otherwise 2.6.X is simply a constantly indeterminent state.

We need to serve users, not just make life easier for kernel developers ;-)

	Jeff

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 03:38:22AM -0500, Jeff Garzik wrote:
> The pertinent question for a point release (2.6.X.Y) would simply be 
> "does a 2.6.11 user really need this fix?"

"need this fix bad enough now, or can it wait until 2.6.12?"

> >Like I previously said, I think we're doing a great job.  The current
> >-mm staging area could use some more testers to help weed out the real
> >issues, and we could do "real" releases a bit faster than every 2 months
> >or so.  But other than that, we have adapted over the years to handle
> >this extremely high rate of change in a pretty sane manner.
> 
> I think Linus's "even/odd" proposal is an admission that 2.6.X releases 
> need some important fixes after it hits kernel.org.

I agree.

> Otherwise 2.6.X is simply a constantly indeterminent state.

Heh, true, but all software is in that state :)

> We need to serve users, not just make life easier for kernel developers ;-)

Damm those pesky users.  Without them our life would be so much
easier...

greg k-h

Re: RFD: Kernel release numbering

[Jeff Garzik]

Greg KH wrote:
> On Thu, Mar 03, 2005 at 03:38:22AM -0500, Jeff Garzik wrote:
> 
>>The pertinent question for a point release (2.6.X.Y) would simply be 
>>"does a 2.6.11 user really need this fix?"
> 
> 
> "need this fix bad enough now, or can it wait until 2.6.12?"
> 
> 
>>>Like I previously said, I think we're doing a great job.  The current
>>>-mm staging area could use some more testers to help weed out the real
>>>issues, and we could do "real" releases a bit faster than every 2 months
>>>or so.  But other than that, we have adapted over the years to handle
>>>this extremely high rate of change in a pretty sane manner.
>>
>>I think Linus's "even/odd" proposal is an admission that 2.6.X releases 
>>need some important fixes after it hits kernel.org.
> 
> 
> I agree.
> 
> 
>>Otherwise 2.6.X is simply a constantly indeterminent state.
> 
> 
> Heh, true, but all software is in that state :)
> 
> 
>>We need to serve users, not just make life easier for kernel developers ;-)
> 
> 
> Damm those pesky users.  Without them our life would be so much
> easier...


hehe :)

I do honestly worry that sometimes we lose sight of what best serves our 
users.

We need to not only produce a useful kernel, but also package it in a 
way that is useful to the direct consumers of the kernel:  distros 
[large and small] and power users.

What do those direct consumers really want?  What best serves them?

	Jeff

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> We need to not only produce a useful kernel, but also package it in a 
>  way that is useful to the direct consumers of the kernel:  distros 
>  [large and small] and power users.

This comes down to the question "what are we making"?  Is it an end
product, or is it a technology which can be turned into an end product? 
Because the two are different things.

I'd say that mainline kernel.org for the past couple of years has been a
technology, not a product.

We do put effort into productising that technology every couple of months
because that's what a (very important) minority of our users want, and
because it is good discipline, but productisation hasn't been the main
focus.

If we were to get serious with maintenance of 2.6.x.y streams then that is
a 100% productisation activity.  It's a very useful activity, and there is
demand for it.  But it is a very different activity.  And a lot of this
discussion has been getting these two activities confused.



But there's something else:

I would maintain that we're still fixing stuff faster than we're breaking
stuff.  If you look at the fixes which are going into the tree (and there
are a HUGE number of fixes), many of them are addressing problems which have
been there for a long time.

So as long as we remain in this state, we don't need to do anything.  The
technology gets closer to a product until we reach the stage where the
fixage rate equals the breakage rate.   And we're not there yet.

(It's nice that patches are called "fix the frobnozzle gadget", but this
analysis would be a lot easier if people would also label their patches
"break the frobnozzle gadget" when that's what they do.  Oh well).

So I'd suspect that on average, kernel releases are getting more stable. 
But the big big problem we have is that even though we fixed ten things for
each one thing we broke, those single breakages tend to be prominent, and
people get upset.  It's fairly bad PR that Dell Inspiron keyboards don't
work in 2.6.11, for example...

And people will incorrectly (and even wildly) generalise as a result of
such silly little isolated bugs.  We can wholly address such problems with
a 2.6.x.y productisation series.



And something else:

I don't think 2.2 and 2.4 models are applicable any more.  There are more
of us, we're better (and older) than we used to be, we're better paid (and
hence able to work more), our human processes are better and the tools are
better.  This all adds up to a qualitative shift in the rate and accuracy
of development.  We need to take this into account when thinking about
processes.

It's important to remember that all those kernel developers out there
*aren't going to stop typing*.  They're just going to keep on spewing out
near-production-quality code with the very reasonable expectation that
it'll become publically available in less than three years.  We need
processes which will allow that.




And another else:


Many people on this mailing list want a super-stable kernel as their first
(and sometimes only) priority (the product group).  But others have other
requirements: to make their code avaialble, or to get their hardware
supported, or to fix that scalability problem (the technology group).  The
product group's interests are in conflict with the technology group's. 

There will be no solution to this problem which is completely satisfactory
to either party.


>  What do those direct consumers really want?  What best serves them?

That's the primary question, of course.

Except I'd replace the term "consumers" with the more general term
"customers".  And I'd then say that, for example, the SGI Altix development
group is a customer of the kernel development team.

And how do we satisfy that customer?  By merging scary patches and hence
screwing your "consumers" ;)

oops.  Tension..

Re: RFD: Kernel release numbering

[Wichert Akkerman]

Previously Andrew Morton wrote:
> I'd say that mainline kernel.org for the past couple of years has been a
> technology, not a product.

If you consider mainline a technology and distributions your main users,
what is the use of a stable release every months or two months? No
distribution is going to updates its release that often. Looking at the
Debian kernel packages it took at least a month just to get a single
release ready for distro use. Needless to say, Debian (or any other
distro) is not going to go through that for every release.

We already saw that with 2.0, 2.2 and 2.4 kernels: distributions rarely
used the last mainline release but older released with (a sometimes
huge amount of) patches.

So continueing that thought pattern; why not go for something like 6
month release cycles? That seems to fit with a distro release cycles.

> So I'd suspect that on average, kernel releases are getting more stable. 
> But the big big problem we have is that even though we fixed ten things for
> each one thing we broke, those single breakages tend to be prominent, and
> people get upset.  It's fairly bad PR that Dell Inspiron keyboards don't
> work in 2.6.11, for example...

same for latitude keyboards after a resume I just discovered :(

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: RFD: Kernel release numbering

[Andrew Morton]

Wichert Akkerman <wichert@wiggy.net> wrote:
>
> Previously Andrew Morton wrote:
>  > I'd say that mainline kernel.org for the past couple of years has been a
>  > technology, not a product.
> 
>  If you consider mainline a technology and distributions your main users,
>  what is the use of a stable release every months or two months?

I don't know, because we've never tried it.  One can only speculate, and
I'd speculate that the kernel would end up pretty crappy because there
would never be a point in time when the thing was sufficiently usable.

The need to periodically lock things down and concentrate on stability and
generally get our act together every couple of months is good discipline
even if we're only making a technology, IMO.  And it gets more testers.

>  So continueing that thought pattern; why not go for something like 6
>  month release cycles? That seems to fit with a distro release cycles.

That could work.  The releases are slowing down as we spend longer wringing
out bugs.  Six months would be a bit excessive though.

But before solutions are discussed, we need to work out what the question was.

What are we trying to fix, and why?

>  > So I'd suspect that on average, kernel releases are getting more stable. 
>  > But the big big problem we have is that even though we fixed ten things for
>  > each one thing we broke, those single breakages tend to be prominent, and
>  > people get upset.  It's fairly bad PR that Dell Inspiron keyboards don't
>  > work in 2.6.11, for example...
> 
>  same for latitude keyboards after a resume I just discovered :(

You know what to do ;)

Re: RFD: Kernel release numbering

[Jeff Garzik]

Rather than mixing problem and solution, let me just define the two 
problems in this thread:


1) There is no clear, CONSISTENT point where "bugfixes only" begins. 
Right now, it could be -rc2, -rc3, -rc4... who knows.

We need to send a clear signal to users "this is when you can really 
start hammering it."  A signal that does not change from release to 
release.  A signal that does not require intimate knowledge of the 
kernel devel process.

This is a key reason why we don't get more pre-release testing.


2) After 2.6.11 release is out, there is no established process for "oh 
shit, 2.6.11 users will really want that fixed."


--------------------


Linus's even/odd proposal is an example of a solution for problem #2, as 
is my 2.6.X.Y proposal.

The 2.4.x series -pre/-rc is an example of a solution for problem #1.

	Jeff

Re: RFD: Kernel release numbering

[Wichert Akkerman]

Previously Jeff Garzik wrote:
> We need to send a clear signal to users "this is when you can really 
> start hammering it."  A signal that does not change from release to 
> release.  A signal that does not require intimate knowledge of the 
> kernel devel process.

The problem I see with that is that the majority is going to wait until
one or two releases after that point since the first 'stablization
point' since that the first such release will not have received much
testing yet. Just like the .0 release for a lot of projects turns
out to a beta version even though they had a seperate beta test.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: RFD: Kernel release numbering

[Chris Wright]

* Jeff Garzik (jgarzik@pobox.com) wrote:
> 1) There is no clear, CONSISTENT point where "bugfixes only" begins. 
> Right now, it could be -rc2, -rc3, -rc4... who knows.
> 
> We need to send a clear signal to users "this is when you can really 
> start hammering it."  A signal that does not change from release to 
> release.  A signal that does not require intimate knowledge of the 
> kernel devel process.
> 
> This is a key reason why we don't get more pre-release testing.
> 
> 2) After 2.6.11 release is out, there is no established process for "oh 
> shit, 2.6.11 users will really want that fixed."
> 
> --------------------
> 
> Linus's even/odd proposal is an example of a solution for problem #2, as 
> is my 2.6.X.Y proposal.
> 
> The 2.4.x series -pre/-rc is an example of a solution for problem #1.

This is exactly how I see it as well.  Guess we drank the same koolaid ;-)
I don't see the reluctance to use -pre/-rc since that's already what
we're doing (just poorly encoded in -rc$x).  Also, .x.y does require
some release discipline, there may be cases where the .x.y fix should be
much simpler than .x+1-pre/rc fix (as in Greg's comment that fixes may
include basic API changes).

thanks,
-chris

Re: RFD: Kernel release numbering

[Krzysztof Halasa]

Jeff Garzik <jgarzik@pobox.com> writes:

> 1) There is no clear, CONSISTENT point where "bugfixes only"
> begins. Right now, it could be -rc2, -rc3, -rc4... who knows.
>
> We need to send a clear signal to users "this is when you can really
> start hammering it."  A signal that does not change from release to
> release.  A signal that does not require intimate knowledge of the
> kernel devel process.

I think so.

> 2) After 2.6.11 release is out, there is no established process for
> "oh shit, 2.6.11 users will really want that fixed."

We can do 2.6.11.x scheme. For the last stable kernel, of course
(i.e., one additional small patchset). No more 2.6.11.x when 2.6.12
is out.

> The 2.4.x series -pre/-rc is an example of a solution for problem #1.

Yes.
But, to shorten the time between stable kernels, I would limit
number of "pre"s. Maybe 1 or even no "pre" kernel is enough?
Massive updates would take place before rc1 is released, of course.
-- 
Krzysztof Halasa

Re: RFD: Kernel release numbering

[Christoph Hellwig]

On Thu, Mar 03, 2005 at 08:41:02PM +0100, Krzysztof Halasa wrote:
> > 2) After 2.6.11 release is out, there is no established process for
> > "oh shit, 2.6.11 users will really want that fixed."
> 
> We can do 2.6.11.x scheme. For the last stable kernel, of course
> (i.e., one additional small patchset). No more 2.6.11.x when 2.6.12
> is out.

I'd rather say we don't guarantee there will be one anymore after 2.6.<next>.2
is out.  First we need to provide it a little longer because .0 isn't alwaysas
stable as we want, second people will fix up older releases when they are
used as base kernel for distributions, and there's no point of not marking it
official if it is there.

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 02:15 -0800, Andrew Morton wrote:
> If we were to get serious with maintenance of 2.6.x.y streams then that is
> a 100% productisation activity.  It's a very useful activity, and there is
> demand for it.

Correct. That's what -ac and -as kernels try to achieve. Moving those
activities into 2.6.x.y would be easier to understand for users.

> But it is a very different activity.  And a lot of this
> discussion has been getting these two activities confused.

Ack.

> Many people on this mailing list want a super-stable kernel as their first
> (and sometimes only) priority (the product group).  But others have other
> requirements: to make their code avaialble, or to get their hardware
> supported, or to fix that scalability problem (the technology group).  The
> product group's interests are in conflict with the technology group's. 
> 
> There will be no solution to this problem which is completely satisfactory
> to either party.

Right, but moving to the even/odd scheme is worse. Even versions will be
ignored within no time like the -rc versions are now. The result will be
that the "stable" odd releases will be less frequent and the -rc phase
of those will be as hard to sell to testers as the current ones. We will
end up with 2.6.ODD in the same shape as we do now with 2.6.x releases.

Moving to a -preX / rcX scheme might help to convince users to give the
-rc versions a try and help to stabilze for the real release.

What about:
2.6-mm	
2.6-devel
2.6.x-stable

-mm 	bleeding edge
-devel	stabilized from -mm and subsystems
-stable stabilized from devel and real bugfixes

In this case the current -rc scheme could work in a real "release
candidate" scheme. 

The devel tree would not be bound to release cycles and would just
contain ongoing development, so the held back pile of changes is not
growing up in the way it does now.

tglx

Re: RFD: Kernel release numbering

[Adrian Bunk]

On Thu, Mar 03, 2005 at 02:15:06AM -0800, Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> > We need to not only produce a useful kernel, but also package it in a 
> >  way that is useful to the direct consumers of the kernel:  distros 
> >  [large and small] and power users.
> 
> This comes down to the question "what are we making"?  Is it an end
> product, or is it a technology which can be turned into an end product? 
> Because the two are different things.
> 
> I'd say that mainline kernel.org for the past couple of years has been a
> technology, not a product.
>...

Even-numbered kernels started becoming a product after the next 
odd-numbered kernel series started.

2.4 might have it's limitations, but today it's a pretty good product.

> But there's something else:
> 
> I would maintain that we're still fixing stuff faster than we're breaking
> stuff.  If you look at the fixes which are going into the tree (and there
> are a HUGE number of fixes), many of them are addressing problems which have
> been there for a long time.
> 
> So as long as we remain in this state, we don't need to do anything.  The
> technology gets closer to a product until we reach the stage where the
> fixage rate equals the breakage rate.   And we're not there yet.
> 
> (It's nice that patches are called "fix the frobnozzle gadget", but this
> analysis would be a lot easier if people would also label their patches
> "break the frobnozzle gadget" when that's what they do.  Oh well).
> 
> So I'd suspect that on average, kernel releases are getting more stable. 
> But the big big problem we have is that even though we fixed ten things for
> each one thing we broke, those single breakages tend to be prominent, and
> people get upset.  It's fairly bad PR that Dell Inspiron keyboards don't
> work in 2.6.11, for example...
> 
> And people will incorrectly (and even wildly) generalise as a result of
> such silly little isolated bugs.  We can wholly address such problems with
> a 2.6.x.y productisation series.

The point behind this is:

It's not the most important question for a user whether the total number 
of bugs has decreased or increased.

The most serious problems for users are regressions compared to the 
kernel before.

If a user who is happily using 2.6.8 learned that "stable" kernel 2.6.9 
broke driver A for him and "stable" kernel 2.6.10 broke driver B for 
him, he will not try any new "stable" kernel simply because it only 
causes trouble for him.

Bad luck, if he therefore misses some serious security fix.

And yes, there are many people out there who use for many different 
reasons self-compiled kernels.

> And something else:
> 
> I don't think 2.2 and 2.4 models are applicable any more.  There are more
> of us, we're better (and older) than we used to be, we're better paid (and
> hence able to work more), our human processes are better and the tools are
> better.  This all adds up to a qualitative shift in the rate and accuracy
> of development.  We need to take this into account when thinking about
> processes.
> 
> It's important to remember that all those kernel developers out there
> *aren't going to stop typing*.  They're just going to keep on spewing out
> near-production-quality code with the very reasonable expectation that
> it'll become publically available in less than three years.  We need
> processes which will allow that.
>...

The traditional solution was to have a development series for the 
developers who don't stop typing and a stable series with few 
regresssions.

Until now, it seems 2.6 has too many regressions in every new released 
kernel for being a really stable kernel.

And people aren't dumb - you can't fool them with any version number 
games. People have learned that a -rc by Linus is equivalent to a -pre 
release by Marcelo. And they will quickly learn that a 2.6.<even> 
kernel will be equivalent to a -pre releaese by Marcelo.

What about thinking instead how to get a 2.7 cycle that roughly fits 
everyones needs?

It took two years from 2.5.0 to 2.6.0 .
That was long. Let's try to shorten it.

Make the feature freeze half a year after the start of 2.5 instead of 
one year as was done in 2.5 . This cuts off half a year of the two 
years. Yes, it really cuts off half a year, because the first year of 
2.5 also included half a year of IDE changes where even the bravest 
kernel developer didn't dare to test the kernel.

Perhaps there are also ways how the more developers, better tools and 
processes can help in shortening the one year after halloween.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFD: Kernel release numbering

[Bill Rugolsky Jr.]

On Thu, Mar 03, 2005 at 02:15:06AM -0800, Andrew Morton wrote:
> If we were to get serious with maintenance of 2.6.x.y streams then that is
> a 100% productisation activity.  It's a very useful activity, and there is
> demand for it.  But it is a very different activity.  And a lot of this
> discussion has been getting these two activities confused.
 
IMHO, Jeff Garzik has made two very useful points in this thread:

1. The number of changesets flowing towards the Linus kernel is accelerating,
   so the kernel developers should be trying to accelerate the merging process,
   not introducing delays.  Having an extended -rc period that stuffs up merging
   just creates back pressure and causes changesets that could be getting
   reviewed, merged, and booted somewhere to instead lie dormant.

2. No matter what one calls it, -rc1, .<odd>, or just 2.6.X these days,
   intelligent consumers know a "dot-zero" release when they see one.
   [I've had experience of several boneheaded corporate policies dictating
    an unpatched kernel.org kernel, but they are uninteresting users.]  The
   class of users that want to use the kernel in production are going to
   wait days to weeks, no matter what.  The trick is in encouraging everyone
   else to overcome inertia and test new releases.

As part of a solution to the "production kernel" problem, Jeff suggested a
2.6.x.y tree that gets pulled to 2.6.x+1.  Neil Brown made a similar point:

   For the kernel, I am the "distribution" for my employer and I choose
   which kernel to use, with which patches.  I really don't want to hunt
   around for all those stablisation patches, or sift through the patches
   in 2.6.X+1-pre to find things to apply to 2.6.X.  I would be really
   happy there was a central place where maintainers can put suitably  
   reviewed "important bug fix"es for recent releases, and from where
   kernel maintainers for any distribution (official or not) could pull
   them.

I'm in the same boat with Neil. Determined to stay reasonably close
to mainline, I started in the 2.6.9-bk series to try to nail down a
stable production kernel. I spent about two months reading lkml and
bk-commits-head, picking through -mm for patches that might be important
for my workloads (e.g., vmtrunc), and spending my days with "quilt",
merging up a new -bk kernel every few days, backing out "dangerous
changes", and retesting. At 2.6.10, I stopped revving up and started
to just merge fixes from 2.6.11-bk.

I'm sure Neil and I are not alone.  I perceive four groups of users for
kernel.org users, with differing requirements:

	1. Developers.  For them, the Linus kernel is a synchronization
	   point for merging, as well as their personal test environment.

	2. "Casual" end-users who like to build their own kernels, and for 
           whom a kernel oops, crash, or driver failure is not a big
	   hassle; they just reboot into their previous kernel.  They are
	   content if a new kernel doesn't corrupt their data.

	3. "Production" end-users, who need a kernel that is going to run
	   stably, usually on many servers, indefinitely [until a bug or
	   desired feature forces an upgrade/reboot].  Rolling out a new
	   kernel is a hassle, and is usually done to fix a serious kernel
	   bug or driver problem.

	4. Vendors, who need a long period of stabilization and testing,
	   as well as a (vendor-internal) mechanism for determining what
	   features, drivers, etc.  to support.

As individuals, many of us live in multiple categories, e.g., I'm a (3) at work,
and a mix of (2) [laptop] and (3) [file server] at home.

Greg KH complained:

   Bug fixes for what?  Kernel api changes that fix bugs?  That's pretty
   big.  Some driver fixes, but not others?  Driver fixes that are in the
   middle of bigger, subsystem reworks as a series of patches?  All of this
   currently happens today in the main tree in a semi-cohesive manner.  To
   try to split it out is a very difficult task.

Opinions will differ, but I think things are a lot more clear-cut than
Greg allows.  I certainly don't expect to download, build, and deploy
a kernel devoid of patches without expecting at least a few problems.  It's
the incredible duplication of effort to sort through thousands of changesets in
order to cull dozens to hundreds, with the result that everyone is running
a subtly different kernel core.  And most of us are far less qualified
than subsystem maintainers to evaluate the risk of individual changesets.

Folks in categories (3) and (4) care very deeply about subtle corruption
[like the recent pty lost bytes], even if rare, as well as easily
triggerable oopses, races, deadlock, livelock, resource leaks, massive
performance regressions, and serious breakage in the (rapidly evolving)
networking stack.  These belong in 2.6.x.y.  API changes do not, unless
they are required to fix one if the above.

Sure, this is going to create situations, such as just occurred, where the
change to 4-level tables meant that some later patches require a bit of
love before they'll apply to the previous 2.6.X release or vice-versa;
but it isn't an everyday occurence.

Driver fixes?  For category (3) users, if one doesn't have the hardware,
or the driver is not broken with the end-user's hardware, one mostly
doesn't care about driver fixes.  Vendors, like Dave Jones, are of course
in a different position, because a vendor kernel is a different animal that
needs to work everywhere, or bug trackers starts filling up quickly.

Dave has been building "unstable" bleeding-edge Fedora kernels from
2.6.x-rcM-bkN, as well as "test" kernels for Fedora updates; they simply
aren't receiving enough testing, and/or the bug reports are going to the wrong
place.  Similarly, Arjan has been building rpms for Alan's kernels; those
kernels are "vanilla" -ac.

Part of the problem here is that most users install e.g., Fedora Core,
and don't enable "testing" in their package manager; judging by the
Fedora lists, many don't even know about it.  [Or don't know or care
that they could limit updates from "testing" or "unstable" to just the
kernel or other packages that allow multiple versions to be installed;
the update would simply fail if a new udev or whatever is required,
prompting admin intervention].  This  contrast with the much
slower-moving Debian, where getting useful work done often requires
running parts of "testing" or even "unstable".

There is a large universe of desktop and laptop users who reboot their
machines every day, and would probably run the most up-to-date kernel
when they boot every morning, confident that they can simply reboot
into the last working kernel if there is a problem.  But it doesn't happen,
because it is not automatic.   In order for this to happen we need
new kernels to be installed automatically and made the default, on
systems where the admin has elected to do so, and a policy for cleaning
up old kernels that are unused (haven't been used for the last N boots
or whatever).

So in short, I'm saying that solutions to the stable kernel problem and
the testing problem are not necessarily solved with a single mechanism.

The testing situation would be improved if a distro install asked the
end-users whether they'd like to participate in kernel testing, explain
the importance of it, and then set up their package manager cron scripts
accordingly (-linus, -mm, -ac, whatever).  I believe the onus here is
on the distros to convince their "hobbyist/enthusiast/sysadmin" users
to help them test before wider release.

Regards,

	Bill Rugolsky

Re: RFD: Kernel release numbering

[Dave Jones]

On Thu, Mar 03, 2005 at 12:07:59PM -0500, Bill Rugolsky Jr. wrote:

 > IMHO, Jeff Garzik has made two very useful points in this thread:
 > 
 > 1. The number of changesets flowing towards the Linus kernel is accelerating,
 >    so the kernel developers should be trying to accelerate the merging process,
 >    not introducing delays.

If you accelerate the merging process, you're lowering the review process.
The only answer to get regressions fixed up as quickly as possible
(because prevention is nigh on impossible at the current rate, so
 any faster is just absurd), would be more regular releases, so that
they got spotted quicker.

 > Dave has been building "unstable" bleeding-edge Fedora kernels from
 > 2.6.x-rcM-bkN, as well as "test" kernels for Fedora updates;

Actually only rawhide (FC4-to-be) has been getting -rc-bk patches.
The FC2/FC3 updates have been release versions only, with -ac patches.
(and also some additional patches backing out bits of the -ac)
During a test cycle (Ie, after FC4test1 is released, but before FC4 gold)
is the only time Fedora users regularly test a -rc-bk tree.
This is part of the problem with rebasing the existing releases to
new kernels. It's shoving a largely untested codebase into a release
that was never tested in that combination. It's expected that some
stuff will break, but the volume of breakage is increasing as time goes on.
Even if _I_ stopped rebasing the Fedora kernel, some of our users
will still want to build and run the latest kernel.org kernel on their
FC2 boxes. We shouldn't be expecting them to have to rebuild half of
their userspace just because we've been sloppy and broke interfaces.

		Dave

Re: RFD: Kernel release numbering

[Bill Rugolsky Jr.]

On Thu, Mar 03, 2005 at 02:33:58PM -0500, Dave Jones wrote:
> If you accelerate the merging process, you're lowering the review process.
> The only answer to get regressions fixed up as quickly as possible
> (because prevention is nigh on impossible at the current rate, so
>  any faster is just absurd), would be more regular releases, so that
> they got spotted quicker.

Right.  My point, and I think Jeff's, was that being extra careful for
the 'even' releases and waiting around N days to see whether someone will
finally test the -rc and see that it is broken impedes the whole process.
Getting more people to test is not necessarily a function of the wait
duration.

>  > Dave has been building "unstable" bleeding-edge Fedora kernels from
>  > 2.6.x-rcM-bkN, as well as "test" kernels for Fedora updates;
> 
> Actually only rawhide (FC4-to-be) has been getting -rc-bk patches.

When Arjan started testing 2.6, he set up a repo, and FC1 users at
the time could just pull rpms from that repo.  I and many others did it.
Currently I'm rolling my own, so I haven't been consistently testing
your Fedora kernels, rawhide or update, but I occasionally do the "grab
the SRPM from Rawhide and rebuild it on FC3"-thing for my laptop.  I
think that we should institutionalize that.

> The FC2/FC3 updates have been release versions only, with -ac patches.
> (and also some additional patches backing out bits of the -ac)

I've watched you periodically announce "hey, I'm doing an update for
FC3/FC2, please test" on the mail list, and a handful of people go test.
If we could convince many of the the less risk-averse but lazy users to
grab kernels automatically from updates/3/testing/ or updates/3/unstable/
as part of "yum update", and have a way to manage the plethora of (even
daily) kernel updates by removing old unused kernels, then we'd only
have to convince them *once* to set up their YUM repos, and then get them
to poweroff or reboot [or use a Xen domain] occasionally. :-)

> This is part of the problem with rebasing the existing releases to
> new kernels. It's shoving a largely untested codebase into a release
> that was never tested in that combination. It's expected that some
> stuff will break, but the volume of breakage is increasing as time goes on.
> Even if _I_ stopped rebasing the Fedora kernel, some of our users
> will still want to build and run the latest kernel.org kernel on their
> FC2 boxes. We shouldn't be expecting them to have to rebuild half of
> their userspace just because we've been sloppy and broke interfaces.
 
Yes, this is miserable, and exacerbated by the inability of almost all
distros to deal with multiple installed versions of packages, or easily
roll back changes, which crimps my argument w.r.t. wider testing, since
the typical user willing to test while otherwise doing useful work wants to
be able to roll back easily if there is a serious problem.

The LVM packaging situation between 2.4 and 2.6 illustrated the problem
well; one couldn't boot back into 2.4 unless LVM1 and LVM2 userland
could coexist; I spent time rolling packages back then to do just that.
In any case, kernel helper packages (udev, device-mapper, iptables, etc.)
need to be added to a "kernel+related" package repo.

Users could be encouraged to do more testing if they are provided
with a simple mechanism to snapshot, update, test, and then either
keep the changes or roll back.  I do this in UML with the COW tools.
Currently LVM2 has writable snapshots, but no easy way (at system boot)
to reintegrate the changes into the base from a snapshot, or "fallback"
to a snapshot.  Still, using Xen/UML/QEMU, it is not difficult to take
advantage of copy-on-write to update the kernel and other packages, then
boot the image to start a shell or web/ftp/mail/... daemon(s).  At least
that would exercise the non-hardware-related, (and for now, non-SMP)
parts of the kernel.

	Bill Rugolsky

Re: RFD: Kernel release numbering

[Jeff Garzik]

Bill Rugolsky Jr. wrote:
> I've watched you periodically announce "hey, I'm doing an update for
> FC3/FC2, please test" on the mail list, and a handful of people go test.
> If we could convince many of the the less risk-averse but lazy users to
> grab kernels automatically from updates/3/testing/ or updates/3/unstable/
> as part of "yum update", and have a way to manage the plethora of (even
> daily) kernel updates by removing old unused kernels, then we'd only
> have to convince them *once* to set up their YUM repos, and then get them
> to poweroff or reboot [or use a Xen domain] occasionally. :-)


Tangent:  I would like to see requests-for-testing for FC kernels on LKML.

If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why not distro 
kernels?

	Jeff

Re: RFD: Kernel release numbering

[Adrian Bunk]

On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote:
> Bill Rugolsky Jr. wrote:
> >I've watched you periodically announce "hey, I'm doing an update for
> >FC3/FC2, please test" on the mail list, and a handful of people go test.
> >If we could convince many of the the less risk-averse but lazy users to
> >grab kernels automatically from updates/3/testing/ or updates/3/unstable/
> >as part of "yum update", and have a way to manage the plethora of (even
> >daily) kernel updates by removing old unused kernels, then we'd only
> >have to convince them *once* to set up their YUM repos, and then get them
> >to poweroff or reboot [or use a Xen domain] occasionally. :-)
> 
> 
> Tangent:  I would like to see requests-for-testing for FC kernels on LKML.
> 
> If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why not distro 
> kernels?

Debian unstable currently contains only for kernel 2.6.8 (which is AFAIK 
still the main kernel in Debian unstable although there are also 2.6.10 
sources and 2.6.10 kernel images on some architectures) for eight 
different architectures - many of them containing or depending on their 
own patches.

How big is the value of a

  New 2.6.8-5 s390 kernel images for Debian unstable - please test!

or a

  New 2.2.25-4 atari kernel images for Debian unstable - please test!

on LKML?


Note that there are currently 42 (what a number ;-) ) different packages 
that build 2.2, 2.4 and 2.6 kernels images in Debian unstable plus the 
packages that build the kernel images for the 11 architectures in Debian 
stable.
Considering how many other distributions exist, this generates a serious 
amount of extra traffic on LKML if a security hole gets fixed that 
affects many kernel versions...

> 	Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFD: Kernel release numbering

[Andres Salomon]

On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote:

> On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote:
>> Bill Rugolsky Jr. wrote:
>> >I've watched you periodically announce "hey, I'm doing an update for
>> >FC3/FC2, please test" on the mail list, and a handful of people go test.
>> >If we could convince many of the the less risk-averse but lazy users to
>> >grab kernels automatically from updates/3/testing/ or updates/3/unstable/
>> >as part of "yum update", and have a way to manage the plethora of (even
>> >daily) kernel updates by removing old unused kernels, then we'd only
>> >have to convince them *once* to set up their YUM repos, and then get them
>> >to poweroff or reboot [or use a Xen domain] occasionally. :-)
>> 
>> 
>> Tangent:  I would like to see requests-for-testing for FC kernels on LKML.
>> 
>> If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why not distro 
>> kernels?
> 
> Debian unstable currently contains only for kernel 2.6.8 (which is AFAIK 
> still the main kernel in Debian unstable although there are also 2.6.10 
> sources and 2.6.10 kernel images on some architectures) for eight 
> different architectures - many of them containing or depending on their 
> own patches.
> 

There's also no other (suitable) place to announce kernel trees.  Debian
kernels get announced on various debian-related lists; I'd imagine FC
kernels have the same thing.  The only place to announce non-distro trees
is lkml (and I've had requests for an -as specific announce list, I
haven't haven't found the time to get something going).

Re: RFD: Kernel release numbering

[Willy Tarreau]

On Sun, Mar 06, 2005 at 02:53:26AM -0500, Andres Salomon wrote:
 
> There's also no other (suitable) place to announce kernel trees.  Debian
> kernels get announced on various debian-related lists; I'd imagine FC
> kernels have the same thing.  The only place to announce non-distro trees
> is lkml (and I've had requests for an -as specific announce list, I
> haven't haven't found the time to get something going).

Andres,

considering that your kernels' purpose is to provide a stabler base than
mainline to people who still want to stay close to mainline, I think that
your announces bring some real value here.

What does not have its place here are the announces of full-featured
patchsets not targetted at developpers nor testers.

Cheers,
Willy

Re: RFD: Kernel release numbering

[Alan Cox]

On Sul, 2005-03-06 at 07:53, Andres Salomon wrote:
> On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote:
> There's also no other (suitable) place to announce kernel trees.  Debian
> kernels get announced on various debian-related lists; I'd imagine FC
> kernels have the same thing.  The only place to announce non-distro trees
> is lkml (and I've had requests for an -as specific announce list, I
> haven't haven't found the time to get something going).

Please keep announcing them here - its useful to see all the trees in
one place. I certainly look at the others to make sure I don't miss
stuff. We might not agree on what should be merged but the cross
checking is valuable.

Re: RFD: Kernel release numbering

[szonyi calin]

 --- Jeff Garzik <jgarzik@pobox.com> a écrit : 
> 
> Tangent:  I would like to see requests-for-testing for FC
> kernels on LKML.
> 
> If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why
> not distro 
> kernels?
> 
> 

Because some people switched to other distribution also 
because of the distribution kernel ;-).

When i was using redhat (6.x) the only compilable kernel 
was from kernel.org. I couldn't get the kernel shipped by
 redhat to compile on my machine.

--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:

 > I would not keep regular driver updates from a 2.6.<even> thing. 

Then the notion of it being stable is bogus, given how many regressions
the last few kernels have brought in drivers.  Moving from 2.6.9 -> 2.6.10
broke ALSA, USB, parport, firewire, and countless other little bits and
pieces that users tend to notice.

The reason that things like 4-level page tables worked out so well
was that it was tested in -mm for however long, so by the time it got
to your tree, the silly bugs had already been shaken out.

Compare this to random-driver-update.  -mm testing is a valuable
proving ground, but its no panacea to stability. There's no guarantee
that someone with $affected_device even tried a -mm kernel.

For it to truly be a stable kernel, the only patches I'd expect to
drivers would be ones fixing blindingly obvious bugs. No cleanups.
No new functionality. I'd even question new hardware support if it
wasn't just a PCI ID addition.

		Dave

Re: RFD: Kernel release numbering

[Randy.Dunlap]

Dave Jones wrote:
> On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
> 
>  > I would not keep regular driver updates from a 2.6.<even> thing. 
> 
> Then the notion of it being stable is bogus, given how many regressions
> the last few kernels have brought in drivers.  Moving from 2.6.9 -> 2.6.10
> broke ALSA, USB, parport, firewire, and countless other little bits and
> pieces that users tend to notice.
> 
> The reason that things like 4-level page tables worked out so well
> was that it was tested in -mm for however long, so by the time it got
> to your tree, the silly bugs had already been shaken out.
> 
> Compare this to random-driver-update.  -mm testing is a valuable
> proving ground, but its no panacea to stability. There's no guarantee
> that someone with $affected_device even tried a -mm kernel.
> 
> For it to truly be a stable kernel, the only patches I'd expect to
> drivers would be ones fixing blindingly obvious bugs. No cleanups.
> No new functionality. I'd even question new hardware support if it
> wasn't just a PCI ID addition.

Maybe I don't understand?  Is someone expecting distro
quality/stability from kernel.org kernels?
I don't, but maybe I'm one of those minorities.

-- 
~Randy

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote:

 > >For it to truly be a stable kernel, the only patches I'd expect to
 > >drivers would be ones fixing blindingly obvious bugs. No cleanups.
 > >No new functionality. I'd even question new hardware support if it
 > >wasn't just a PCI ID addition.
 > 
 > Maybe I don't understand?  Is someone expecting distro
 > quality/stability from kernel.org kernels?

My complaint is the charade of calling it 'stable' when it clearly
wouldn't be anything of the sort, given that a majority of the bugs our
users experienced on rebasing were driver related.
The core itself may be rock-solid, but if we're continually pulling
in random driver updates of questionable quality with limited
testing, the result as a whole isn't stable.

 > I don't, but maybe I'm one of those minorities.

Putting the onus on distributions to make things stable is no
excuse for the ever-increasing number of regressions each release.

This might sound over-dramatic, but it's the current state as far
as I'm concerned.  The 2.6.8->2.6.9 update for Fedora users brought
a bunch of carnage that took time to shake out. 2.6.9->2.6.10 I'm
still picking up the pieces of.  If the 2.6.10->2.6.11 update that
I'll do for Fedora in a week or two turns out to have less regressions
than the previous releases, I'll be stunned. Really.

Already I'm wondering how many userspace packages are going to randomly
stop working as they have done in previous releases.  With the
clear delineation of stable/development, we were able to say things
like "we won't change a user visible interface in a stable series"
Now, we don't have that. So we find things ranging from slabtop to
alsa-lib completely break unless you update the userspace too.

regressions like this is what I'm bitching about. There's nothing
a vendor can do to make such things stable (other than dropping
the various patches that introduce the breakage, but at ~4000 csets
per release right now, there will be stuff that gets missed).
Whilst the slabinfo example was a non-driver related regression,
it's a good example of how little care we're taking these days
to make sure existing userspace continues to work correctly.

Some may suggest the close tracking of mainline is the problem.
Maybe they're right. Maybe we should have stuck with a 2.6.5 kernel
until Fedora Core 2 reached end of life, and gone with the old
'have hundreds and hundreds of patches piling up' approach.

But, as someone who has maintained vendor kernels that have tried
both methods, the sticking close to mainline approach wins hands down.
If something is broken, more often than not, I can bug the upstream
developer and ask "hey, this is a wierd problem our fedora users hit,
we don't have any patches against this code, can you take a look?"
and developers have been very responsive, and helpful on many occasions,
ultimatly leading bugs being fixed both in our kernel, and upstream.

If I asked most upstream developers about a problem we've been facing
with our 2.6.5 kernels, I'd get a much less helpful response.
And rightly so. In their position I'd do exactly the same thing.

		Dave

Re: RFD: Kernel release numbering

[Randy.Dunlap]

Dave Jones wrote:
> On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote:
> 
>  > >For it to truly be a stable kernel, the only patches I'd expect to
>  > >drivers would be ones fixing blindingly obvious bugs. No cleanups.
>  > >No new functionality. I'd even question new hardware support if it
>  > >wasn't just a PCI ID addition.
>  > 
>  > Maybe I don't understand?  Is someone expecting distro
>  > quality/stability from kernel.org kernels?
> 
> My complaint is the charade of calling it 'stable' when it clearly
> wouldn't be anything of the sort, given that a majority of the bugs our
> users experienced on rebasing were driver related.
> The core itself may be rock-solid, but if we're continually pulling
> in random driver updates of questionable quality with limited
> testing, the result as a whole isn't stable.
> 
>  > I don't, but maybe I'm one of those minorities.
> 
> Putting the onus on distributions to make things stable is no
> excuse for the ever-increasing number of regressions each release.

Sure, I'm not trying to put the onus on distros, just saying
that they add some real value there, but that doesn't excuse
us from trying to make the mainline kernel as good as we can
make it.

> This might sound over-dramatic, but it's the current state as far
> as I'm concerned.  The 2.6.8->2.6.9 update for Fedora users brought
> a bunch of carnage that took time to shake out. 2.6.9->2.6.10 I'm
> still picking up the pieces of.  If the 2.6.10->2.6.11 update that
> I'll do for Fedora in a week or two turns out to have less regressions
> than the previous releases, I'll be stunned. Really.
> 
> Already I'm wondering how many userspace packages are going to randomly
> stop working as they have done in previous releases.  With the
> clear delineation of stable/development, we were able to say things
> like "we won't change a user visible interface in a stable series"
> Now, we don't have that. So we find things ranging from slabtop to
> alsa-lib completely break unless you update the userspace too.
> 
> regressions like this is what I'm bitching about. There's nothing
> a vendor can do to make such things stable (other than dropping
> the various patches that introduce the breakage, but at ~4000 csets
> per release right now, there will be stuff that gets missed).
> Whilst the slabinfo example was a non-driver related regression,
> it's a good example of how little care we're taking these days
> to make sure existing userspace continues to work correctly.
> 
> Some may suggest the close tracking of mainline is the problem.
> Maybe they're right. Maybe we should have stuck with a 2.6.5 kernel
> until Fedora Core 2 reached end of life, and gone with the old
> 'have hundreds and hundreds of patches piling up' approach.
> 
> But, as someone who has maintained vendor kernels that have tried
> both methods, the sticking close to mainline approach wins hands down.
> If something is broken, more often than not, I can bug the upstream
> developer and ask "hey, this is a wierd problem our fedora users hit,
> we don't have any patches against this code, can you take a look?"
> and developers have been very responsive, and helpful on many occasions,
> ultimatly leading bugs being fixed both in our kernel, and upstream.
> 
> If I asked most upstream developers about a problem we've been facing
> with our 2.6.5 kernels, I'd get a much less helpful response.
> And rightly so. In their position I'd do exactly the same thing.

-- 
~Randy

Re: RFD: Kernel release numbering

[Erik Hensema]

Randy.Dunlap (rddunlap@osdl.org) wrote:
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.

There are few distributors who can sufficiently QA the kernel
they ship. I think only Redhat/Fedora, Novell/Suse and
Mandrake/Conectiva currently have *good* testing procedures and
good QA. Most other distributions basically ship the vanilla
Linus kernel (or Alan kernel) with some basic patches applied.

Besides that, a *lot* of admins still prefer to compile their own
kernel. I often encounter admins who still don't know about the
2.6 development scheme and blindly compile each shiny new 2.6
kernel released by Linus.

So basically what I'm trying to tell is: it could be time to
start the 2.7 series to have some room for experimentation. That
is what Linus enjoys doing (*) and that is what Linus is good at.
Leave the 2.6 kernel to Alan or someone else.

However, I think a 2.6.x-mm kernel is still a good idea after 2.7
branches. The -mm kernel could be a collection of backports from
the 2.7 kernel, waiting to be included in the 2.6 kernel.

The 3.x.y kernel could be the place for very wild
experimentation. I'd love to see a kernel which supports a
object-relational non-POSIX compatible filesystem, ready for
2010's storage requirements. But that's just me.

(*) I've got a magic Linus brain reader device.
-- 
Erik Hensema <erik@hensema.net>

Re: RFD: Kernel release numbering

[Jochen Striepe]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

    Hi,

On 02 Mar 2005, Randy.Dunlap wrote:
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.

How do you expect a broad user base testing your kernels if "stable"
kernel.org kernels aren't to be expected stable?


Just my 2p,

Jochen.
-- 
Please place all complaints in this box --> []

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

Re: RFD: Kernel release numbering

[Russell King]

On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote:
> Dave Jones wrote:
> > For it to truly be a stable kernel, the only patches I'd expect to
> > drivers would be ones fixing blindingly obvious bugs. No cleanups.
> > No new functionality. I'd even question new hardware support if it
> > wasn't just a PCI ID addition.
> 
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.

Don't say that too loudly or else the embedded people will use it as
another excuse not to move on to 2.6 kernels.

But yes, _I_ do expect a certain amount of quality and stability from
kernel.org kernels mainly because there _isn't_ a distro to do that
for us on ARM.  It's fine in x86 land where there are such things and
you have One Single Platform(tm), but in ARM land where there's
numerious platforms, there's very little sense in having a "distro"
maintained kernel.

For instance, I'd like to upgrade the kernel on the main ARM server
here from 2.4 to 2.6, but since it requires a number of subsystems to
work properly (MD, Promise IDE, Ext3, NFS server) which you normally
wouldn't see on ARM embedded systems, I'm not entirely happy to throw
a 2.6 kernel on it just yet.

However, coupled with the requirement for quality, some in the ARM
community expect a certain amount of development to be going on, since
ARM is a relatively fast moving community [*].  Freezing stuff for 6
months isn't really practical when you have support for new platforms
or new drivers wanting to be merged all the time.  Ignoring these
things for 6 months causes someone to spawn a new tree and that's
usually the last you see of any contribution from that direction.

So, what I think we need is for core system, subsystem and "service"
development to slow down a little while still allowing peripheral
low-impact "new stuff" to be added during a "stablisation" period.
We also need to qualify what we mean by "stable in relation to the
resulting kernel - eg, I don't think we should call the "new stuff"
merged during that time "stable".

This actually brings up an interesting point - if new machine support
is stablised external to the "stable" tree, and then merged into that
tree, should it be marked as "experimental"?  Given the previous
paragraph, I think the answer is "yes" since this will allow people
to distinguish the recently merged stuff.



[*] - depends how you understand "fast".  My method of working new
features into the ARM code in Linus' kernel is via a series of small
steps (or a series of smaller series of steps) spread out over a
period of time.

An example of this is the ARM SMP merging, where the low level entry
code has had to be rewritten.  However, rather than just replace the
file, it's getting a series of clean ups first which are aimed in the
direction we want to go.  We're getting towards the state where the
_major_ difference between todays implementation and the SMP version
is the code in a small number of macros, rather than virtually every
line in the file.  However, I do feel like I'm going against the grain
when Linus says "slow down" and I'm seen to be doing cleanup after
cleanup with no obvious effect or point.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Jesper Juhl]

On Wed, 2 Mar 2005, Randy.Dunlap wrote:
>
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.
> 
I certainly do, and I think many others do as well.

My assumptions/expectations on vanilla kernels has changed a bit over 
time, and I don't expect as much from them these days as I once did.

I used to expect/assume (and this was back when I had never touched a 
single line of kernel code nor read a single post on lkml), that 1) the 
vanilla kernel was the ones with all the latest bugfixes and features 2) 
the latest stable vanilla kernel had gone through extensive testing 
(manual and automated) to make sure there were no regressions compared to 
the previous release 3) I could always go from <stable_series>.X to 
<stable_series>.X+1 without any features having disappeared 4) that a new 
vanilla kernel would never be released if there were still known bugs in 
it (even if those bugs were not regressions).

I've become wiser since then, and I'm more aware of the level of testing 
actually done, so I expect to be hit by bugs/regressions in vanilla 
kernels once in a while. But I still expect a very high degree of 
stability/quality from stable series vanilla kernels in general..

I run vanilla kernels on all my boxes, workstations and servers, since I 
don't really trust vendor kernels. I don't want to start relying on 
features only available in a single vendors patched kernel so that I will 
have trouble if I switch vendor (or want to get some new feature that's in 
vanilla but has not entered the vendors kernel yet). I've also had bad 
experiences in the past with patched vendor kernels being more unstable on 
my boxes than the vanilla kernels.. and then there's the testing issue, if 
everyone ran vendor kernels then who'd be testing vanilla?


-- 
Jesper Juhl

Re: RFD: Kernel release numbering

[Jens Axboe]

On Fri, Mar 04 2005, Jesper Juhl wrote:
> I run vanilla kernels on all my boxes, workstations and
> servers, since I don't really trust vendor kernels.

That's a strange statement, I don't think you are aware of
the level of testing that goes into a vendor kernel, at
least for the 'enterprise' products. There's just no comparison
to the vanilla kernels.

Of course fixes get merged back into the vanilla kernels, but
these just don't have the lengthy test and maturity period
of vendor kernels (by a long stretch).

In fact the 2.6 cycle is specially geared towards vendor
stabilization. At some point this will slow down of course,
but I don't expect that to happen in the near future.

-- 
Jens Axboe

Re: RFD: Kernel release numbering

[Jesper Juhl]

On Fri, 4 Mar 2005, Jens Axboe wrote:

> On Fri, Mar 04 2005, Jesper Juhl wrote:
> > I run vanilla kernels on all my boxes, workstations and
> > servers, since I don't really trust vendor kernels.
> 
> That's a strange statement, I don't think you are aware of
> the level of testing that goes into a vendor kernel, at
> least for the 'enterprise' products. There's just no comparison
> to the vanilla kernels.
> 
I can't claim to have any detailed knowledge of that, no.

> Of course fixes get merged back into the vanilla kernels, but
> these just don't have the lengthy test and maturity period
> of vendor kernels (by a long stretch).
> 
That's true. I guess my lack of trust in vendor kernels is part being 
bitten by them in the past where my own custom build vanilla kernels have 
worked fine, and part the fear of getting locked-in to some vendor 
specific feature... Perhaps things are different these days and I should 
reevaluate my view on vendor kernels - but that's why I haven't been 
trusting them.


-- 
Jesper

Re: RFD: Kernel release numbering

[Christoph Hellwig]

On Fri, Mar 04, 2005 at 08:41:34PM +0100, Jesper Juhl wrote:
> That's true. I guess my lack of trust in vendor kernels is part being 
> bitten by them in the past where my own custom build vanilla kernels have 
> worked fine, and part the fear of getting locked-in to some vendor 
> specific feature... Perhaps things are different these days and I should 
> reevaluate my view on vendor kernels - but that's why I haven't been 
> trusting them.

Traditionally the vendor kernels from the big two vendors have been full
of crap, for one of them it seems to be slowly changing now..

Re: RFD: Kernel release numbering

[szonyi calin]

 --- "Randy.Dunlap" <rddunlap@osdl.org> a écrit : 
> 
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.
> 

yes. Some people (like me) would like to use from time to time
 some _new_ stable kernel. It's annoying to see that sometimes
kernel people say that you have a hardware problem in 2.6.0 
release and then the bug is silently fixed in a 2.6.5 release
for example. 

The 2.6 kernel is not good enough for desktop -- sound skips on 
a 700Mhz duron when there is a lot (50M of 256) of free memory 
and mozilla is using CPU. 2.4 with preemptible patches was 
better in that respect.

What i would like to really have is a stable version not a demo
version. I like testing but sometimes i also want stability and
it seems that a good enough 2.6 kernel is still away. 
I don't care how you call it 2.6.x.y.z-rc-kappa i just want to 
be sure that it will not mess up my system. 
(and no, i'm not going to use <insert your favourite distro>
kernel )
 
Just my 2 euro cents (if somebody cares)

P.S. I know this message is late. Sorry if it annoys you.

--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: RFD: Kernel release numbering

[Andrew Morton]

Dave Jones <davej@redhat.com> wrote:
>
> On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
> 
>  > I would not keep regular driver updates from a 2.6.<even> thing. 
> 
> Then the notion of it being stable is bogus, given how many regressions
> the last few kernels have brought in drivers.  Moving from 2.6.9 -> 2.6.10
> broke ALSA, USB, parport, firewire, and countless other little bits and
> pieces that users tend to notice.

Grump.  Have all these regressions received the appropriate level of
visibility on this mailing list?

I too am a little put off by the number of regressions which certain
(admittedly tricky) subsystems keep on introducing.  One does wonder how
careful people are being at the development stage.  And that's a thing
which we can surely fix.

For example, here's today's crop (so far):

include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined
include/linux/awe_voice.h:33: warning: this is the location of the previous definition
drivers/i2c/chips/ds1337.c:60: `I2C_DRIVERID_DS1337' undeclared here (not in a function)
drivers/i2c/chips/ds1337.c:60: initializer element is not constant
drivers/i2c/chips/ds1337.c:60: (near initialization for `ds1337_driver.id')
drivers/i2c/chips/ds1337.c: In function `ds1337_get_datetime':
drivers/i2c/chips/ds1337.c:155: structure has no member named `id'
drivers/i2c/chips/ds1337.c: In function `ds1337_set_datetime':
drivers/i2c/chips/ds1337.c:206: structure has no member named `id'
drivers/i2c/chips/ds1337.c: In function `ds1337_detect':
drivers/i2c/chips/ds1337.c:333: structure has no member named `id'
drivers/i2c/chips/ds1337.c:343: structure has no member named `id'
make[3]: *** [drivers/i2c/chips/ds1337.o] Error 1
make[2]: *** [drivers/i2c/chips] Error 2
make[1]: *** [drivers/i2c] Error 2
make[1]: *** Waiting for unfinished jobs....
sound/pci/als4000.c: In function `snd_als4000_create_gameport':
sound/pci/als4000.c:572: warning: `r' might be used uninitialized in this function
drivers/char/watchdog/alim1535_wdt.c:319: warning: `ali_pci_tbl' defined but not used
drivers/char/sx.c:255: warning: `sx_pci_tbl' defined but not used
drivers/char/applicom.c:68: warning: `applicom_pci_tbl' defined but not used
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
sound/pci/trident/trident_main.c: In function `snd_trident_gameport_trigger':
sound/pci/trident/trident_main.c:3125: warning: `return' with a value, in function returning void

> For it to truly be a stable kernel, the only patches I'd expect to
> drivers would be ones fixing blindingly obvious bugs. No cleanups.
> No new functionality. I'd even question new hardware support if it
> wasn't just a PCI ID addition.

Agree.

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
 > Dave Jones <davej@redhat.com> wrote:
 > >
 > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
 > > 
 > >  > I would not keep regular driver updates from a 2.6.<even> thing. 
 > > 
 > > Then the notion of it being stable is bogus, given how many regressions
 > > the last few kernels have brought in drivers.  Moving from 2.6.9 -> 2.6.10
 > > broke ALSA, USB, parport, firewire, and countless other little bits and
 > > pieces that users tend to notice.
 > 
 > Grump.  Have all these regressions received the appropriate level of
 > visibility on this mailing list?

For the most part these things are usually known about by their upstream
authors.  To give an example: ALSA update in 2.6.10 broke sound for a
bunch of IBM thinkpads. As it turns out there are quite a lot of these
out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
up like a christmas tree with "Hey, where'd my sound go?" reports.
(It was further confused by a load of other sound card problems, but
 thats another issue).  This got so out of control, Alan asked the ALSA
folks to take a look, and iirc Takashi figured out what had caused the
problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc.

Now, during all this time, there hadn't been any reports of this problem
at all on Linux-kernel. Not even from Linus' tree, let alone -mm.
Which amazes me given how widespread the problem was.

 > I too am a little put off by the number of regressions which certain
 > (admittedly tricky) subsystems keep on introducing.  One does wonder how
 > careful people are being at the development stage.  And that's a thing
 > which we can surely fix.
 > For example, here's today's crop (so far):
 > 
 > include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined
 > include/linux/awe_voice.h:33: warning: this is the location of the previous definition

compile time regressions we should be able to nail down fairly easily.
(someone from OSDL is already doing compile stats and such on each release
 [too bad they're mostly incomprehensible to the casual viewer])
The bigger problem is runtime testing. If things aren't getting the
exposure they need, we're going to get screwed over by something or other
every time Linus bk pull's some random driver repo.

		Dave

Re: RFD: Kernel release numbering

[Randy.Dunlap]

Dave Jones wrote:
> On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
>  > Dave Jones <davej@redhat.com> wrote:
>  > >
>  > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
>  > > 
>  > >  > I would not keep regular driver updates from a 2.6.<even> thing. 
>  > > 
>  > > Then the notion of it being stable is bogus, given how many regressions
>  > > the last few kernels have brought in drivers.  Moving from 2.6.9 -> 2.6.10
>  > > broke ALSA, USB, parport, firewire, and countless other little bits and
>  > > pieces that users tend to notice.
>  > 
>  > Grump.  Have all these regressions received the appropriate level of
>  > visibility on this mailing list?
> 
> For the most part these things are usually known about by their upstream
> authors.  To give an example: ALSA update in 2.6.10 broke sound for a
> bunch of IBM thinkpads. As it turns out there are quite a lot of these
> out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
> up like a christmas tree with "Hey, where'd my sound go?" reports.
> (It was further confused by a load of other sound card problems, but
>  thats another issue).  This got so out of control, Alan asked the ALSA
> folks to take a look, and iirc Takashi figured out what had caused the
> problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc.
> 
> Now, during all this time, there hadn't been any reports of this problem
> at all on Linux-kernel. Not even from Linus' tree, let alone -mm.
> Which amazes me given how widespread the problem was.
> 
>  > I too am a little put off by the number of regressions which certain
>  > (admittedly tricky) subsystems keep on introducing.  One does wonder how
>  > careful people are being at the development stage.  And that's a thing
>  > which we can surely fix.
>  > For example, here's today's crop (so far):
>  > 
>  > include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined
>  > include/linux/awe_voice.h:33: warning: this is the location of the previous definition
> 
> compile time regressions we should be able to nail down fairly easily.
> (someone from OSDL is already doing compile stats and such on each release
>  [too bad they're mostly incomprehensible to the casual viewer])
> The bigger problem is runtime testing. If things aren't getting the
> exposure they need, we're going to get screwed over by something or other
> every time Linus bk pull's some random driver repo.

I'll ding the OSDL release builder about that (I agree with you)....

-- 
~Randy

Re: RFD: Kernel release numbering

[Lee Revell]

On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
> On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
>  > Dave Jones <davej@redhat.com> wrote:
>  > >
>  > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
>  > > 
>  > >  > I would not keep regular driver updates from a 2.6.<even> thing. 
>  > > 
>  > > Then the notion of it being stable is bogus, given how many regressions
>  > > the last few kernels have brought in drivers.  Moving from 2.6.9 -> 2.6.10
>  > > broke ALSA, USB, parport, firewire, and countless other little bits and
>  > > pieces that users tend to notice.
>  > 
>  > Grump.  Have all these regressions received the appropriate level of
>  > visibility on this mailing list?
> 
> For the most part these things are usually known about by their upstream
> authors.  To give an example: ALSA update in 2.6.10 broke sound for a
> bunch of IBM thinkpads. As it turns out there are quite a lot of these
> out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
> up like a christmas tree with "Hey, where'd my sound go?" reports.
> (It was further confused by a load of other sound card problems, but
>  thats another issue).  This got so out of control, Alan asked the ALSA
> folks to take a look, and iirc Takashi figured out what had caused the
> problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc.
> 
> Now, during all this time, there hadn't been any reports of this problem
> at all on Linux-kernel. Not even from Linus' tree, let alone -mm.
> Which amazes me given how widespread the problem was.

There is not much the ALSA developers can do about this, because we just
do not have access to the 1000s of hardware varieties out there,  and
vendors are inexplicably loath to give out any docs on something as
simple as a cheap shitty laptop AC97 codec.

The usual pattern that leads to a regression like the Thinkpad issue is
that a user reports a bug, a fix is merged, the user reports the problem
is fixed on $FOO hardware, then a week later we are deluged with reports
that $BAR hardware is now broken.

Catching a problem like this before it gets out the door would require
access to 1000s of laptops, unlimited time, and reasonable hardware
documentation.  Chances are we would still miss something.  IOW it's
impossible.

The *only* solution for these kinds of driver regressions is to get more
people to test the release candidates.  "Being more careful" will not
help, because we just don't have access to all of the hardware.

Lee

Re: RFD: Kernel release numbering

[Diego Calleja]

El Thu, 3 Mar 2005 00:21:01 -0500,
Dave Jones <davej@redhat.com> escribió:

> bunch of IBM thinkpads. As it turns out there are quite a lot of these
> out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
> up like a christmas tree with "Hey, where'd my sound go?" reports.
> (It was further confused by a load of other sound card problems, but
>  thats another issue).  This got so out of control, Alan asked the ALSA
> folks to take a look, and iirc Takashi figured out what had caused the
> problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc.
> 
> Now, during all this time, there hadn't been any reports of this problem
> at all on Linux-kernel. Not even from Linus' tree, let alone -mm.
> Which amazes me given how widespread the problem was.

Part of that problem may be that reporting bugs to the kernel is hard for everybody except
kernel hackers. bugzilla.kernel.org is there but not many people look at it (which I
understand, using bugzilla is painfull, altough basing all your development strategy around
it _is_ rewarding, as happens in gnome/etc, where the release announcement includes a
list bugzilla numbers which point to fixed bugs or "new feature" bugs in the case of new
features).

That could be very well at last as important as the "release numbering". If there're bugs
out there and people are not reporting them, the "release numbering" you choose is
irrelevant since bugs are not being reported and you can't fix them. Just my humble
opinion.

Re: RFD: Kernel release numbering

[Russell King]

On Thu, Mar 03, 2005 at 09:43:58PM +0100, Diego Calleja wrote:
> bugzilla.kernel.org is there but not many people look at it (which I
> understand, using bugzilla is painfull, altough basing all your
> development strategy around it _is_ rewarding, as happens in gnome/etc,
> where the release announcement includes a list bugzilla numbers which
> point to fixed bugs or "new feature" bugs in the case of new
> features).

As one of those who initially thought "great" about bugzilla for kernel
stuff, and then got rather annoyed with it, I think I can talk about
why bugzilla doesn't work for kernel developers.

* The most obvious problem is that it requires you to go to the website
  before you can do anything with a bug.
* Bug reporters appear to report a bug and run away - attempting to get
  more information from them sometimes resorts in silence until you
  threaten to close the bug, or do close the bug.
* Bug categories aren't explained well enough to allow users to determine
  the correct category.  Eg, PCMCIA network card - should that be
  networking or PCMCIA (where the bugzilla PCMCIA category is actually
  *only* the PCMCIA core and not any of the drivers.)

Overall, my experience with the kernel bugzilla has been rather
unproductive.  Most bugs which came in my direction weren't for things
I could resolve.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Diego Calleja]

El Fri, 4 Mar 2005 11:06:33 +0000,
Russell King <rmk+lkml@arm.linux.org.uk> escribió:

> Overall, my experience with the kernel bugzilla has been rather
> unproductive.  Most bugs which came in my direction weren't for things
> I could resolve.


It's possible that there're other bug tracking systems that can fit? The main disadvantage 
of the (few) bug tracking systems I've seen is that at the end they end up being a
"additional task" for the developers (ie: more work) instead of being something that really
helps to developers and free them of doing some extra work, so people avoids them when
they can. There're some mail-based bug tracking systems like the one from debian but
they don't include a alternative web interface for final users (well, I think bugzilla has a
"email mode" or something like that but I don't really know)


Bug reporters running away is something that will happen always no matter what system
is used, but is it important? If someone submits a bug and he don't answer when 
he's asked for more details, there's no way you can fix it and the bug should be closed
given a reasonable time frame. There's no reason why this can't happen today when bug
are reported to the lkml, except that people who reports bugs to the lkml is people who
really wants to get their bugs fixed. If the bug is important enought, it'll get reported again
by someone else who cares about getting it fixed.

(There're other problems with traditional bug tracking systems, like "ownership" of a bug.
Some bugs are reported, discussed, and then they get fixed silently outside of the
scope of the bug tracking system, but the bug remains open for _years_ - IMHO all open
bugs which have not been discussed and closed in such amount of time should be
closed unless there're real reasons to keep them open, new versions could have fixed
it and if it remains it could be re-submitted - and it can't get closed because the developer
who owns it is not looking at it. Some bug tracking systems (like the one from joel spolsky,
aka "joelonsoftware.com") just don't allow to have "ownership" of bugs, because if you
want that the system helps to solve problems instead of being an additional task,
_everyone_ should be allowed to solve problems - which is specially true in the open
source world)

Re: RFD: Kernel release numbering

[John Cherry]

On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
<snip>
> compile time regressions we should be able to nail down fairly easily.
> (someone from OSDL is already doing compile stats and such on each release
>  [too bad they're mostly incomprehensible to the casual viewer])

Dave, I'm the "someone from OSDL".  I agree that the compile stats and
error/warning regresssions can be a little challenging to grock for the
casual observer.  Is it content or formatting that would help the casual
viewer?

John

> The bigger problem is runtime testing. If things aren't getting the
> exposure they need, we're going to get screwed over by something or other
> every time Linus bk pull's some random driver repo.
> 
> 		Dave
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: RFD: Kernel release numbering

[Dave Jones]

On Thu, Mar 03, 2005 at 01:49:50PM -0800, John Cherry wrote:
 > On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
 > <snip>
 > > compile time regressions we should be able to nail down fairly easily.
 > > (someone from OSDL is already doing compile stats and such on each release
 > >  [too bad they're mostly incomprehensible to the casual viewer])
 > 
 > Dave, I'm the "someone from OSDL".  I agree that the compile stats and
 > error/warning regresssions can be a little challenging to grock for the
 > casual observer.  Is it content or formatting that would help the casual
 > viewer?

I don't have one handy to quote from, but personally I find there
are two problems with what's currently presented.

1 - information overload. It's just a screenfull of numbers.
2 - the column headings were non-obvious iirc. Or maybe I'm just dumb
    and didn't look at them long enough.

So it could just need some formatting tweaks to make it more
palatable.

		Dave

Re: RFD: Kernel release numbering

[John Cherry]

On Thu, 2005-03-03 at 16:52 -0500, Dave Jones wrote:
> On Thu, Mar 03, 2005 at 01:49:50PM -0800, John Cherry wrote:
>  > On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
>  > <snip>
>  > > compile time regressions we should be able to nail down fairly easily.
>  > > (someone from OSDL is already doing compile stats and such on each release
>  > >  [too bad they're mostly incomprehensible to the casual viewer])
>  > 
>  > Dave, I'm the "someone from OSDL".  I agree that the compile stats and
>  > error/warning regresssions can be a little challenging to grock for the
>  > casual observer.  Is it content or formatting that would help the casual
>  > viewer?
> 
> I don't have one handy to quote from, but personally I find there
> are two problems with what's currently presented.
> 
> 1 - information overload. It's just a screenfull of numbers.
> 2 - the column headings were non-obvious iirc. Or maybe I'm just dumb
>     and didn't look at them long enough.
> 
> So it could just need some formatting tweaks to make it more
> palatable.

This is not too difficult to do.  I'll tweak the format a bit and see if
it is more consumable.

John

> 
> 		Dave

Re: RFD: Kernel release numbering

[szonyi calin]

 --- Dave Jones <davej@redhat.com> a écrit : 
>  > Grump.  Have all these regressions received the appropriate
> level of
>  > visibility on this mailing list?
> 
> For the most part these things are usually known about by
> their upstream
> authors.  To give an example: ALSA update in 2.6.10 broke
> sound for a
> bunch of IBM thinkpads. As it turns out there are quite a lot
> of these
> out there, so when I released a 2.6.10 update for Fedora,
> bugzilla lit
> up like a christmas tree with "Hey, where'd my sound go?"
> reports.
> (It was further confused by a load of other sound card
> problems, but
>  thats another issue).  This got so out of control, Alan asked
> the ALSA
> folks to take a look, and iirc Takashi figured out what had
> caused the
> problem, and it got fixed in the ALSA folks tree, and
> subsequently, in 2.6.11rc.
> 
> Now, during all this time, there hadn't been any reports of
> this problem
> at all on Linux-kernel. Not even from Linus' tree, let alone
> -mm.
> Which amazes me given how widespread the problem was.
> 

I reported once a bug on alsa-devel and cc-ed on lkml 
The sequencer isn't working with my card cs4239 with alsa.


Taking into account that nobody responded on lkml nor
on alsa (the message was awaiting modderator aprouval 
on alsa-devel) i don't think i will send more bug reports 
to alsa. 

Maybe more people are testing the kernel but they don't have 
time to report the bugs (for me it takes about 15 minutes to 
do it properly). And some bugs like "i had a crash last night"
are irrelevant if i don't have some logs traces.

And _you_ (most of you) _want_ _people_ _to_ _test_  
_2.6_ _kernels_ *and in the mean time* _you_ 
_recommend_ _using_ _vendor_ _kernels_. 

So if i want also a stable kernel i should use two trees 
(a vendor tree and a "2.6..whatever" tree) to compile the 
kernel ? How about mm-tree ?
The whole 2.6. tree is strange. On one side you have -mm where
all the "experimental" stuff goes and on the other side there is
Linus's tree (2.6.x) where also some "experimental" stuff goes.
(from a luser/tester point of view)

Also some people need time to test. I have 4 hours free 
every day.




--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.

Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
 Créez votre Yahoo! Mail sur http://mail.yahoo.fr

Re: RFD: Kernel release numbering

[Andrew Morton]

szonyi calin <caszonyi@yahoo.com> wrote:
>
> I reported once a bug on alsa-devel and cc-ed on lkml 
> The sequencer isn't working with my card cs4239 with alsa.
> 

I cannot find your report (checked back to the start of the year).

Please send a new one.  I'm collection them.

Re: RFD: Kernel release numbering

[Lee Revell]

On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote:
>  --- Dave Jones <davej@redhat.com> a écrit : 
> Taking into account that nobody responded on lkml nor
> on alsa (the message was awaiting modderator aprouval 
> on alsa-devel) i don't think i will send more bug reports 
> to alsa. 

How long ago was this?  alsa-devel has been accepting messages from
non-subscribers for at least 6 months.

Lee

Re: RFD: Kernel release numbering

[Lee Revell]

On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote:
> I reported once a bug on alsa-devel and cc-ed on lkml 
> The sequencer isn't working with my card cs4239 with alsa.
> 

What exactly do you mean by "it isn't working"?

90% of "MIDI does not work" bug reports are from users who expect
playing MIDI files to work OOTB like it does on Mac and Windows.

This only works because those OS'es come bundled with a toy softsynth.
With ALSA, you either need a supported hardware wavetable synth
(emu10k1) or a real soft synth like Timidity or Fluidsynth.

Anyway, please repost your bug report to alsa-devel.  There is no point
in cc'ing LKML for ALSA problems, unless you find a problem like a
regression in ALSA functionality from one kernel release to another.

Lee

Re: RFD: Kernel release numbering

[Alan Cox]

On Maw, 2005-03-08 at 23:50, Lee Revell wrote:
> This only works because those OS'es come bundled with a toy softsynth.
> With ALSA, you either need a supported hardware wavetable synth
> (emu10k1) or a real soft synth like Timidity or Fluidsynth.

CS4239 has a toy synth of sorts (its more "doorbell" than synth
admittedly). There are a pile of funnies with IBM laptops and CS423x to
watch out for that might be worth mentioning - in particular you need to
turn the fast boot stuff -off-.

Re: RFD: Kernel release numbering

[Russell King]

On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> Grump.  Have all these regressions received the appropriate level of
> visibility on this mailing list?

Looking at the http://l4x.org/k/ site, it appears that all -mm versions
have broken ARM support with the defconfig, while Linus kernels at least
build fine. I've no idea why though.

I haven't had any reports of breakage, and I don't think I've missed
any heads up on something which needs to be fixed up, except maybe the
4 level page table stuff.  (TBH I don't think many ARM people look at
-mm, but it is worrying that something which may be merged into Linus'
tree from -mm may have the unexpected consequence of breaking something
which used to work.)

Unfortunately, http://l4x.org/k/ doesn't save any build logs for
investigation.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Ian Campbell]

On Fri, 2005-03-04 at 10:52 +0000, Russell King wrote:

> Unfortunately, http://l4x.org/k/ doesn't save any build logs for
> investigation.

If you click the 'Fail' then it seems to keep the make output etc.

Ian.
-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 11:11:38AM +0000, Ian Campbell wrote:
> On Fri, 2005-03-04 at 10:52 +0000, Russell King wrote:
> > Unfortunately, http://l4x.org/k/ doesn't save any build logs for
> > investigation.
> 
> If you click the 'Fail' then it seems to keep the make output etc.

elinks doesn't show any of the "fail" in the matrix as links - this
seems to be using javascript.

In fact there doesn't appear to be a reason to use javascript for
this - it seems to be implementing a standard link to:

	http://l4x.org/k/?d=<number>

which can be done just as well with standard HTML without need to
resort to javascript.  Plus it works with a wider range of browsers.
Including those used by certain blind developers in this community
who are completely unable to use any form of GUI.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Ian Campbell]

On Fri, 2005-03-04 at 11:16 +0000, Russell King wrote:
> On Fri, Mar 04, 2005 at 11:11:38AM +0000, Ian Campbell wrote:
> > On Fri, 2005-03-04 at 10:52 +0000, Russell King wrote:
> > > Unfortunately, http://l4x.org/k/ doesn't save any build logs for
> > > investigation.
> > 
> > If you click the 'Fail' then it seems to keep the make output etc.
> 
> elinks doesn't show any of the "fail" in the matrix as links - this
> seems to be using javascript.
> 
> In fact there doesn't appear to be a reason to use javascript for
> this - it seems to be implementing a standard link to:

The links and row headers high-light when you mouse over each cell,
which appears to be why there is javascript involved at all.

I don't know if javascript is necessary for that feature, but I agree
that using it for the links seems wrong.

Ian.
-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200

Re: RFD: Kernel release numbering

[David Weinehall]

On Fri, Mar 04, 2005 at 11:32:18AM +0000, Ian Campbell wrote:
> On Fri, 2005-03-04 at 11:16 +0000, Russell King wrote:
> > On Fri, Mar 04, 2005 at 11:11:38AM +0000, Ian Campbell wrote:
> > > On Fri, 2005-03-04 at 10:52 +0000, Russell King wrote:
> > > > Unfortunately, http://l4x.org/k/ doesn't save any build logs for
> > > > investigation.
> > > 
> > > If you click the 'Fail' then it seems to keep the make output etc.
> > 
> > elinks doesn't show any of the "fail" in the matrix as links - this
> > seems to be using javascript.
> > 
> > In fact there doesn't appear to be a reason to use javascript for
> > this - it seems to be implementing a standard link to:
> 
> The links and row headers high-light when you mouse over each cell,
> which appears to be why there is javascript involved at all.
> 
> I don't know if javascript is necessary for that feature, but I agree
> that using it for the links seems wrong.

No it isn't necessary; the CSS attribute :hover is the correct way to do
this.  Using Javascript for any kind of design is just wrong, wrong,
wrong.


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: RFD: Kernel release numbering

[Andrew Morton]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
>  > Grump.  Have all these regressions received the appropriate level of
>  > visibility on this mailing list?
> 
>  Looking at the http://l4x.org/k/ site, it appears that all -mm versions
>  have broken ARM support with the defconfig, while Linus kernels at least
>  build fine.

It's very much in an arch maintainer's interest to make sure that
cross-compilers are easily obtainable.  Any hints?

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> >
> > On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> >  > Grump.  Have all these regressions received the appropriate level of
> >  > visibility on this mailing list?
> > 
> >  Looking at the http://l4x.org/k/ site, it appears that all -mm versions
> >  have broken ARM support with the defconfig, while Linus kernels at least
> >  build fine.
> 
> It's very much in an arch maintainer's interest to make sure that
> cross-compilers are easily obtainable.  Any hints?

Been trying to achieve that since it's a FAQ on ARM lists.  Even gone to
the extent of setting up a separate mailing list, getting a volunteer to
track what people want and do the hard work to build them.  That was
about 6 months ago, and I haven't seen any results.

I was thinking at the time "great, this is one problem which should be
solved".  How silly of me.  It seems, yet again, that it comes down to
a case of "if rmk doesn't do it, it won't get done."  Sad but true.
Now, why do I keep feeling that I'm being taken advantage of all the
time?  Could it be the complete lack of productive help from anyone else.

Anyway, going back to why -mm doesn't work:

 arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
 : undefined reference to `rd_size'
 make[1]: *** [.tmp_vmlinux1] Error 1

So "rd_size" got deleted in -mm kernels without reference to anyone else
who's using it.  Greeeeaaatttt....

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Andrew Morton]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> > Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > >
> > > On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> > >  > Grump.  Have all these regressions received the appropriate level of
> > >  > visibility on this mailing list?
> > > 
> > >  Looking at the http://l4x.org/k/ site, it appears that all -mm versions
> > >  have broken ARM support with the defconfig, while Linus kernels at least
> > >  build fine.
> > 
> > It's very much in an arch maintainer's interest to make sure that
> > cross-compilers are easily obtainable.  Any hints?
> 
> Been trying to achieve that since it's a FAQ on ARM lists.  Even gone to
> the extent of setting up a separate mailing list, getting a volunteer to
> track what people want and do the hard work to build them.  That was
> about 6 months ago, and I haven't seen any results.

hm.  That's strange.  I'd have thought that 99% of the arm embedded
developers cross-build.

> Anyway, going back to why -mm doesn't work:
> 
>  arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
>  : undefined reference to `rd_size'
>  make[1]: *** [.tmp_vmlinux1] Error 1
> 
> So "rd_size" got deleted in -mm kernels without reference to anyone else
> who's using it.  Greeeeaaatttt....

Ah.  Fixed, thanks.

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 03:44:10AM -0800, Andrew Morton wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> > > Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > >
> > > > On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> > > >  > Grump.  Have all these regressions received the appropriate level of
> > > >  > visibility on this mailing list?
> > > > 
> > > >  Looking at the http://l4x.org/k/ site, it appears that all -mm versions
> > > >  have broken ARM support with the defconfig, while Linus kernels at least
> > > >  build fine.
> > > 
> > > It's very much in an arch maintainer's interest to make sure that
> > > cross-compilers are easily obtainable.  Any hints?
> > 
> > Been trying to achieve that since it's a FAQ on ARM lists.  Even gone to
> > the extent of setting up a separate mailing list, getting a volunteer to
> > track what people want and do the hard work to build them.  That was
> > about 6 months ago, and I haven't seen any results.
> 
> hm.  That's strange.  I'd have thought that 99% of the arm embedded
> developers cross-build.

Yes - I think Dan Kegel's cross-tool gets used a fair bit...

> > Anyway, going back to why -mm doesn't work:
> > 
> >  arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
> >  : undefined reference to `rd_size'
> >  make[1]: *** [.tmp_vmlinux1] Error 1

Actually, this highlights another problem - it's ARM binutils again.
Jan's cross-binutils for ARM doesn't contain the patches to make the
linker resolve addresses to the _correct_ symbol.  Don't ask me
where they are, but I'm lead to believe that cross-tool knows.

This also means that Jan's compile test is rather worthless for ARM -
it might be linking a kernel with undefined symbols due to the other
assembler bug.

> Ah.  Fixed, thanks.

Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Richard Purdie]

Russell King:
>> It's very much in an arch maintainer's interest to make sure that
>> cross-compilers are easily obtainable.  Any hints?
>
> I was thinking at the time "great, this is one problem which should be
> solved".  How silly of me.  It seems, yet again, that it comes down to
> a case of "if rmk doesn't do it, it won't get done."  Sad but true.
> Now, why do I keep feeling that I'm being taken advantage of all the
> time?  Could it be the complete lack of productive help from anyone else.

I've found the arm cross compiler generated from openembedded 
(http://openembedded.org) to be very reliable. The big advantage in using oe 
would be that it is in active use so it is always highly likely to generate 
a working compiler. Someone just needs to make it generate a 
toolchain/compiler for external use[1], make it available somewhere and 
advertise the fact its available. Generation of the toolchain could probably 
be almost entirely automated.

Fixes for any problems with compiler would be more than welcome for 
incorporation into oe short term and for submission upstream for "proper" 
fixing.

[1] I think I've seen reference that it can already do this...

Richard 

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 12:40:30PM -0000, Richard Purdie wrote:
> I've found the arm cross compiler generated from openembedded 
> (http://openembedded.org) to be very reliable. The big advantage in using oe 
> would be that it is in active use so it is always highly likely to generate 
> a working compiler. Someone just needs to make it generate a 
> toolchain/compiler for external use[1], make it available somewhere and 
> advertise the fact its available. Generation of the toolchain could probably 
> be almost entirely automated.
> 
> Fixes for any problems with compiler would be more than welcome for 
> incorporation into oe short term and for submission upstream for "proper" 
> fixing.

I'll only believe it when I see it.  The problem is this "someone"...
Who's going to forfill that space and produce some results?

Something tells me that we'll be very lucky to get a volunteer, let
alone see any results.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Richard Purdie]

Russell King:
> On Fri, Mar 04, 2005 at 12:40:30PM -0000, Richard Purdie wrote:
>> I've found the arm cross compiler generated from openembedded
>> (http://openembedded.org) to be very reliable. The big advantage in using 
>> oe
>> would be that it is in active use so it is always highly likely to 
>> generate
>> a working compiler. Someone just needs to make it generate a
>> toolchain/compiler for external use[1], make it available somewhere and
>> advertise the fact its available. Generation of the toolchain could 
>> probably
>> be almost entirely automated.
>
> I'll only believe it when I see it.  The problem is this "someone"...
> Who's going to forfill that space and produce some results?
>
> Something tells me that we'll be very lucky to get a volunteer, let
> alone see any results.

As an experiment I ran "bitbake meta-sdk" on my copy of openemedded. A while 
later I have these in the deploy directory amongst other things.

http://www.rpsys.net/openzaurus/arm-cross/binutils-cross-sdk-2.15.91.0.2-r5.tar.gz 
(3.8MB)
http://www.rpsys.net/openzaurus/arm-cross/gcc-cross-sdk-3.4.2-r0.tar.gz 
(17.5MB)

"bitbake binutls-cross-sdk" and "bitbake gcc-cross-sdk" are more efficient 
as they won't build all the other things in the sdk.

Generating a cross compiler from oe really is as simple as that. Setting up 
oe in the first place is a bit more tricky but too bad.

An improvement to the current situation might be some instructions and links 
to oe to tell people they can build a toolchain this way. Better still 
someone could run the above commands now and again and upload the files 
somewhere. I don't have anywhere I can host files that size on a permanent 
basis. I possibly could be persuaded to run the commands now and again if 
people were going to use the results. I'm in two minds though as generating 
your own from openembedded isn't difficult. Writing instructions for setting 
up oe to build it may be the best option.

Richard 

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 05:33:33PM -0000, Richard Purdie wrote:
> I'm in two minds though as generating 
> your own from openembedded isn't difficult. Writing instructions for setting 
> up oe to build it may be the best option.

Two things - are you sure that openembedded contains the patches to
fix the two biggest binutils issues we have, as documented on
http://www.arm.linux.org.uk/developer/toolchain/ ?

Secondly, are you seriously suggesting people like Jan Dittmer, who
provide a cross-architecture service should jump through some loops
just to get a working toolchain for the ARM architecture?

Jan, how do you feel about this?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Jan Dittmer]

Russell King wrote:
> On Fri, Mar 04, 2005 at 05:33:33PM -0000, Richard Purdie wrote:
> 
>>I'm in two minds though as generating 
>>your own from openembedded isn't difficult. Writing instructions for setting 
>>up oe to build it may be the best option.
> 
> 
> Two things - are you sure that openembedded contains the patches to
> fix the two biggest binutils issues we have, as documented on
> http://www.arm.linux.org.uk/developer/toolchain/ ?
> 
> Secondly, are you seriously suggesting people like Jan Dittmer, who
> provide a cross-architecture service should jump through some loops
> just to get a working toolchain for the ARM architecture?

As long it is documented and it _works_ that's no problem. But it was
quite a hassle to get working cross-compilers for all 23 archs
to build, because for some there is no real documentation which
target is the correct one and upstream gcc and/or binutils sometimes
don't compile.
For example where can I find information about the arm26 arch?
I suppose it can be build with a normal arm toolchain (and the
breakage looks like a real compiler failure), but is this documented
somewhere?
It would be nice to have such documentation in kernel under
Documentation/$arch/HOW-TO-BUILD for every arch.
How much work is it to set-up an openembedded environment anyways?

Jan

-- 
http://l4x.org/k/

Re: RFD: Kernel release numbering

[Richard Purdie]

Russell King:
> Two things - are you sure that openembedded contains the patches to
> fix the two biggest binutils issues we have, as documented on
> http://www.arm.linux.org.uk/developer/toolchain/ ?

I've checked and it contains the tc-arm.c.patch but does not have the ARM
mapping symbols fix. As recent kernels have fixes for that, its not so much
of a problem as it was however it should be staightforward to add into oe
and I will aim to do that.

> Secondly, are you seriously suggesting people like Jan Dittmer, who
> provide a cross-architecture service should jump through some loops
> just to get a working toolchain for the ARM architecture?

You said nobody was willing/interested in maintaining a toolchain. I'm
saying that a toolchain is maintained within openembedded and that pointing
people at that is better than nothing. Maintaining a set of patches to
ensure bugs in binutils etc are fixed is easy within oe's framework. (To add
the above patch, in theory I just need to add a line to a file).

Jan Dittmer:
> As long it is documented and it _works_ that's no problem. But it was
> quite a hassle to get working cross-compilers for all 23 archs
> to build, because for some there is no real documentation which
> target is the correct one and upstream gcc and/or binutils sometimes
> don't compile.

This is why openembedded exists - it tracks known working build
configurations of every bit of software needed to make complete linux
distributions.

> How much work is it to set-up an openembedded environment anyways?

I've written a quick and dirty set of instructions on setting up
openembedded below. Please note that oe is used for building complete linux
distributions so there is a lot of functionality being unused here (as you
can imagine from my statement above). bitbake is a known memory hog (it can
use up to 1GB of ram) - we all know this is appalling and a rewrite to
address this is in progress.

cd /work/
svn co svn://svn.berlios.de/bitbake/trunk/bitbake
export PATH=/work/bitbake/bin:$PATH

bk clone bk://openembedded.bkbits.net/openembeded
export BBPATH=/work/build:/work/openembedded

mkdir build
mkdir build/conf/
cp openembedded/conf/local.conf.sample build/conf/local.conf

Edit local.conf as appropriate. local.conf.sample has details about what
the variables do. My local.conf to generate the arm toolchain has:

DL_DIR="/work/sources"
BBFILES="/work/openembedded/packages/*/*.bb"
TARGET_ARCH="arm"
TARGET_OS="linux"
INHERIT="package_tar"

(everything else is left unchanged)

cd build
bitbake binutils-cross-sdk
bitbake gcc-cross-sdk

Output ends up in /work/build/tmp/deploy

Richard

Re: RFD: Kernel release numbering

[David Greaves]

Richard Purdie wrote:

> Writing instructions for setting up oe to build it may be the best 
> option.

As it happens I was editing that exact page in the wiki t'other day:
  http://openembedded.org/cgi-bin/moin.cgi/GettingStarted

I actually only wanted a toolchain but oe and scratchbox[1] seemed the 
rational alternatives.
Scratchbox seems to offer : arm-gcc-3.3.4-glibc-2.3.2 but I've not 
gotten round to using it yet.

Thanks for the comment on "bitbake binutils-cross-sdk" and "bitbake 
gcc-cross-sdk".
I'll add more notes to the page once I figure it all out.

David

[1] http://www.scratchbox.org/download/scratchbox-1.0/

Re: RFD: Kernel release numbering

[Andrew Morton]

"Richard Purdie" <rpurdie@rpsys.net> wrote:
>
> As an experiment I ran "bitbake meta-sdk" on my copy of openemedded. A while 
> later I have these in the deploy directory amongst other things.
> 
> http://www.rpsys.net/openzaurus/arm-cross/binutils-cross-sdk-2.15.91.0.2-r5.tar.gz 
> (3.8MB)
> http://www.rpsys.net/openzaurus/arm-cross/gcc-cross-sdk-3.4.2-r0.tar.gz 
> (17.5MB)

Bless you.  I just built an arm kernel!

That compiler is *fast*.  47 seconds.  Weird.

For reference, untar the above in / and use


#!/bin/sh
export ARCH=arm
export CROSS_COMPILE=arm-linux-
W=/usr/local/arm/oe/bin

MAKE="make"

if [ -z "$1" ]
then
	WHAT="vmlinux"
else
	WHAT="$1"
fi

nr_cpus=$(grep processor /proc/cpuinfo|wc -l)
j=$(expr $nr_cpus \* 3 / 2)

MAKE_ARGS="ARCH=$ARCH CROSS_COMPILE=$W/arm-linux-"

if [ x"$DISTCC_HOSTS" != x ]
then
	$MAKE -j 12 CC="ccache distcc --ccache-skip $W/$CROSS_COMPILE""gcc" $MAKE_ARGS $WHAT 2>/tmp/log
else
	$MAKE -j $j $MAKE_ARGS CC="$W/$CROSS_COMPILE""gcc" $WHAT 2>/tmp/log
fi
cat /tmp/log


That's now eight architectures I'll compile-test mm kernels on.

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> That's now eight architectures I'll compile-test mm kernels on.

Cool, but please check whether this produces an error:

echo "mov r0, #foo" | arm-linux-as -o /dev/null -

you should get:
{standard input}: Assembler messages:
{standard input}:1: Error: undefined symbol foo used as an immediate value

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Andrew Morton]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> > That's now eight architectures I'll compile-test mm kernels on.
> 
> Cool, but please check whether this produces an error:
> 
> echo "mov r0, #foo" | arm-linux-as -o /dev/null -
> 
> you should get:
> {standard input}: Assembler messages:
> {standard input}:1: Error: undefined symbol foo used as an immediate value

I did get that.

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 02:48:08PM -0800, Andrew Morton wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> >
> > On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> > > That's now eight architectures I'll compile-test mm kernels on.
> > 
> > Cool, but please check whether this produces an error:
> > 
> > echo "mov r0, #foo" | arm-linux-as -o /dev/null -
> > 
> > you should get:
> > {standard input}: Assembler messages:
> > {standard input}:1: Error: undefined symbol foo used as an immediate value
> 
> I did get that.

Great - this will help ensure that any breakage due to that binutils
problem should get caught relatively quickly no matter how it gets in
to either your or Linus' kernel.  This is a definite plus.  Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Adrian Bunk]

On Fri, Mar 04, 2005 at 11:36:26AM +0000, Russell King wrote:
>...
> Anyway, going back to why -mm doesn't work:
> 
>  arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
>  : undefined reference to `rd_size'
>  make[1]: *** [.tmp_vmlinux1] Error 1
> 
> So "rd_size" got deleted in -mm kernels without reference to anyone else
> who's using it.  Greeeeaaatttt....

Sorry, this was my fault (I made it static and oversaw the ARM usage 
when grep'ing for it).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFD: Kernel release numbering

[Russell King]

On Fri, Mar 04, 2005 at 11:36:26AM +0000, Russell King wrote:
> On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> > Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > >
> > > On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> > >  > Grump.  Have all these regressions received the appropriate level of
> > >  > visibility on this mailing list?
> > > 
> > >  Looking at the http://l4x.org/k/ site, it appears that all -mm versions
> > >  have broken ARM support with the defconfig, while Linus kernels at least
> > >  build fine.
> > 
> > It's very much in an arch maintainer's interest to make sure that
> > cross-compilers are easily obtainable.  Any hints?
> 
> Been trying to achieve that since it's a FAQ on ARM lists.  Even gone to
> the extent of setting up a separate mailing list, getting a volunteer to
> track what people want and do the hard work to build them.  That was
> about 6 months ago, and I haven't seen any results.
> 
> I was thinking at the time "great, this is one problem which should be
> solved".  How silly of me.  It seems, yet again, that it comes down to
> a case of "if rmk doesn't do it, it won't get done."  Sad but true.
> Now, why do I keep feeling that I'm being taken advantage of all the
> time?  Could it be the complete lack of productive help from anyone else.
> 
> Anyway, going back to why -mm doesn't work:
> 
>  arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
>  : undefined reference to `rd_size'
>  make[1]: *** [.tmp_vmlinux1] Error 1
> 
> So "rd_size" got deleted in -mm kernels without reference to anyone else
> who's using it.  Greeeeaaatttt....

And guess what?  This patch is now in Linus kernel. Greeeeaaaattttt
stuff whoever did that.  Truely wonderful job.

Thanks for taking notice of me a month ago.  I really appreciate it.
Especially when stuff gets merged which has already been pointed out
as needlessly _BREAKING_ stuff.

Linus - please revert the change which caused this.

  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
arch/arm/kernel/built-in.o(.init.text+0x9d4): In function `$a':
: undefined reference to `rd_size'
make: *** [.tmp_vmlinux1] Error 1

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Andrew Morton]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> > So "rd_size" got deleted in -mm kernels without reference to anyone else
> > who's using it.  Greeeeaaatttt....
> 
> And guess what?  This patch is now in Linus kernel. Greeeeaaaattttt
> stuff whoever did that.  Truely wonderful job.

megamolehill, Russell.

> Thanks for taking notice of me a month ago.

I immediately dropped that patch when the problem was pointed out.

But early this month Adrian resent the same patch and I applied it again
and it slipped through.

> I really appreciate it.
> Especially when stuff gets merged which has already been pointed out
> as needlessly _BREAKING_ stuff.

Stuff happens.  That's why we have -rc kernels.

I already have the fix for this queued up.

Re: RFD: Kernel release numbering

[Jan Dittmer]

Russell King wrote:
> On Fri, Mar 04, 2005 at 11:36:26AM +0000, Russell King wrote:
> 
>>On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
>>
>>>Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>>>
>>>>On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
>>>> > Grump.  Have all these regressions received the appropriate level of
>>>> > visibility on this mailing list?
>>>>
>>>> Looking at the http://l4x.org/k/ site, it appears that all -mm versions
>>>> have broken ARM support with the defconfig, while Linus kernels at least
>>>> build fine.

Sorry for tapping in so late. I don't follow lkml that close. For some time
I thought about providing semi-automatic mails of what architectures broke/
got fixed from one version to another, tracking mm/rc/git(?). Would that
be useful?

-- 
Jan

Re: RFD: Kernel release numbering

[Russell King]

On Sat, May 07, 2005 at 12:51:41PM +0200, Jan Dittmer wrote:
> Sorry for tapping in so late. I don't follow lkml that close. For some time
> I thought about providing semi-automatic mails of what architectures broke/
> got fixed from one version to another, tracking mm/rc/git(?). Would that
> be useful?

We have http://armlinux.simtec.co.uk/kautobuild/ setup for ARM -
it would be nice if it could generate mail reports and send them
out, especially when failures occur.

I think it would need some post-processing and rate limiting to
determine if there is a common problem across multiple platforms
(eg, 40 builds failing due to rd_size), or just one platform (some
local breakage).

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: RFD: Kernel release numbering

[Jan Dittmer]

Russell King wrote:
> On Sat, May 07, 2005 at 12:51:41PM +0200, Jan Dittmer wrote:
> 
>>Sorry for tapping in so late. I don't follow lkml that close. For some time
>>I thought about providing semi-automatic mails of what architectures broke/
>>got fixed from one version to another, tracking mm/rc/git(?). Would that
>>be useful?
> 
> 
> We have http://armlinux.simtec.co.uk/kautobuild/ setup for ARM -
> it would be nice if it could generate mail reports and send them
> out, especially when failures occur.
> 
> I think it would need some post-processing and rate limiting to
> determine if there is a common problem across multiple platforms
> (eg, 40 builds failing due to rd_size), or just one platform (some
> local breakage).

Well I built something like this now which I mail to myself,
overlook and then going sent to lkml:

Comparing 2.6.12-rc3-mm2 to 2.6.12-rc3-mm3 (defconfig)

- arm: broke
    AR      arch/arm/lib/lib.a
    GEN     .version
    CHK     include/linux/compile.h
    UPD     include/linux/compile.h
    CC      init/version.o
    LD      init/built-in.o
    LD      .tmp_vmlinux1
  arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
  : undefined reference to `rd_size'
  make[1]: *** [.tmp_vmlinux1] Error 1
  make: *** [_all] Error 2
  Details: http://l4x.org/k/?d=3476

- m32r: broke
  : relocation truncated to fit: R_M32R_26_PCREL_RELA pcibus_to_node
  drivers/built-in.o(.text+0x46258): In function `init_irq':
  : undefined reference to `pcibus_to_node'
  drivers/built-in.o(.text+0x46258): In function `init_irq':
  : relocation truncated to fit: R_M32R_26_PCREL_RELA pcibus_to_node
  drivers/built-in.o(.text+0x4a15c): In function `idedisk_attach':
  : undefined reference to `pcibus_to_node'
  drivers/built-in.o(.text+0x4a15c): In function `idedisk_attach':
  : relocation truncated to fit: R_M32R_26_PCREL_RELA pcibus_to_node
  make[1]: *** [vmlinux] Error 1
  make: *** [_all] Error 2
  Details: http://l4x.org/k/?d=3483

- ppc: fixed

- um: fixed

- arm26: still broken
  Details: http://l4x.org/k/?d=3477

- cris: still broken
  Details: http://l4x.org/k/?d=3478

- frv: still broken
  Details: http://l4x.org/k/?d=3479

- h8300: still broken
  Details: http://l4x.org/k/?d=3480

- ia64: still broken
  Details: http://l4x.org/k/?d=3482

- m68k: still broken
  Details: http://l4x.org/k/?d=3484

- m68knommu: still broken
  Details: http://l4x.org/k/?d=3486

- parisc: still broken
  Details: http://l4x.org/k/?d=3488

- s390: still broken
  Details: http://l4x.org/k/?d=3491

- sh: still broken
  Details: http://l4x.org/k/?d=3492

- sh64: still broken
  Details: http://l4x.org/k/?d=3493

- v850: still broken
  Details: http://l4x.org/k/?d=3497

Summary: 8 ok, 14 failed
Link to this page: http://l4x.org/k/?diff[v1]=mm

-- 
Jan

Re: RFD: Kernel release numbering

[Adrian Bunk]

On Sat, May 07, 2005 at 03:20:02PM +0200, Jan Dittmer wrote:
> 
> Well I built something like this now which I mail to myself,
> overlook and then going sent to lkml:

Seems to be valuable.

> Comparing 2.6.12-rc3-mm2 to 2.6.12-rc3-mm3 (defconfig)
> 
> - arm: broke
>...
>   arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a':
>   : undefined reference to `rd_size'
>   make[1]: *** [.tmp_vmlinux1] Error 1
>   make: *** [_all] Error 2
>   Details: http://l4x.org/k/?d=3476
>...

Known issue (was my fault).

I'll send separate emails regarding some other issues the output shows.

> Jan

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

select of non-existing I2C* symbols

[Adrian Bunk]

On Sat, May 07, 2005 at 03:20:02PM +0200, Jan Dittmer wrote:
>...
> Link to this page: http://l4x.org/k/?diff[v1]=mm

arm26, cris, sparc: select of non-existing I2C* symbols:

@ Ian, Mikael, William:
This could be fixed by sourcing drivers/i2c/Kconfig in arch/*/Kconfig,
but it would be better to switch to use drivers/Kconfig.

@ Roman:
Shouldn't kconfig exit with an error if a not available symbol gets
selected?


> Jan

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [kbuild-devel] select of non-existing I2C* symbols

[Sam Ravnborg]

> Shouldn't kconfig exit with an error if a not available symbol gets
> selected?
No. There are meny configurations where we select a symbol that is
only visible in some configurations.

Several possibilities exists:
1) Silently ignore SELECT SYMBOL when SYMBOL is undefined
2) Warn - as we do today
3) Error out as you suggest

Option 1) is preferable for 'make oldconfig' simply because target group
here do not care. But it would be nice to know when one do a typing
error in SELECT. So one *config target should continue to warn about it.

	Sam

Re: [kbuild-devel] select of non-existing I2C* symbols

[Russell King]

On Sun, May 08, 2005 at 08:20:50PM +0200, Sam Ravnborg wrote:
> > Shouldn't kconfig exit with an error if a not available symbol gets
> > selected?
> No. There are meny configurations where we select a symbol that is
> only visible in some configurations.
> 
> Several possibilities exists:
> 1) Silently ignore SELECT SYMBOL when SYMBOL is undefined
> 2) Warn - as we do today
> 3) Error out as you suggest
> 
> Option 1) is preferable for 'make oldconfig' simply because target group
> here do not care. But it would be nice to know when one do a typing
> error in SELECT. So one *config target should continue to warn about it.

I disagree.

Consider that some developers do not use anything other than "make
oldconfig" so having this silently ignore stuff means that these
folk never get the warnings.  I myself fall into this category.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [kbuild-devel] select of non-existing I2C* symbols

[Adrian Bunk]

On Sun, May 08, 2005 at 08:20:50PM +0200, Sam Ravnborg wrote:
> > Shouldn't kconfig exit with an error if a not available symbol gets
> > selected?
> No. There are meny configurations where we select a symbol that is
> only visible in some configurations.
> 
> Several possibilities exists:
> 1) Silently ignore SELECT SYMBOL when SYMBOL is undefined
> 2) Warn - as we do today
> 3) Error out as you suggest
> 
> Option 1) is preferable for 'make oldconfig' simply because target group
> here do not care. But it would be nice to know when one do a typing
> error in SELECT. So one *config target should continue to warn about it.

I'd prefer 3) and fix up all problems.

E.g. i the case of the I2C* select's the current warnings seem to 
indicate possible configurations that do not compile.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: select of non-existing I2C* symbols

[William Lee Irwin III]

On Sat, May 07, 2005 at 03:20:02PM +0200, Jan Dittmer wrote:
>>...
>> Link to this page: http://l4x.org/k/?diff[v1]=mm

On Sat, May 07, 2005 at 04:41:35PM +0200, Adrian Bunk wrote:
> arm26, cris, sparc: select of non-existing I2C* symbols:
> @ Ian, Mikael, William:
> This could be fixed by sourcing drivers/i2c/Kconfig in arch/*/Kconfig,
> but it would be better to switch to use drivers/Kconfig.
> @ Roman:
> Shouldn't kconfig exit with an error if a not available symbol gets
> selected?

You're telling me I have to futz with the i2c Kconfig just to cope with
it not existing?


-- wli

Re: select of non-existing I2C* symbols

[Adrian Bunk]

On Wed, May 11, 2005 at 07:30:10AM -0700, William Lee Irwin III wrote:
> On Sat, May 07, 2005 at 03:20:02PM +0200, Jan Dittmer wrote:
> >>...
> >> Link to this page: http://l4x.org/k/?diff[v1]=mm
> 
> On Sat, May 07, 2005 at 04:41:35PM +0200, Adrian Bunk wrote:
> > arm26, cris, sparc: select of non-existing I2C* symbols:
> > @ Ian, Mikael, William:
> > This could be fixed by sourcing drivers/i2c/Kconfig in arch/*/Kconfig,
> > but it would be better to switch to use drivers/Kconfig.
> > @ Roman:
> > Shouldn't kconfig exit with an error if a not available symbol gets
> > selected?
> 
> You're telling me I have to futz with the i2c Kconfig just to cope with
> it not existing?

What happens if a user selects one of the options that do themself 
select one or more of the I2C* options?

This might be solved differently (e.g. via some kind of 
ARCH_SUPPORTS_I2C), but it should be solved.

> -- wli

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: select of non-existing I2C* symbols

[William Lee Irwin III]

On Wed, May 11, 2005 at 07:30:10AM -0700, William Lee Irwin III wrote:
>> You're telling me I have to futz with the i2c Kconfig just to cope with
>> it not existing?

On Thu, May 12, 2005 at 12:50:57AM +0200, Adrian Bunk wrote:
> What happens if a user selects one of the options that do themself 
> select one or more of the I2C* options?
> This might be solved differently (e.g. via some kind of 
> ARCH_SUPPORTS_I2C), but it should be solved.

I've got a patch to convert arch/sparc/Kconfig to sourcing drivers/Kconfig.
I've checked that defconfig comes out largely the same (the difference
seems to be order and comments) but haven't really checked thoroughly.

Maybe if others (e.g. sparc32 users) could look and complain if
something goes wrong that would help.

vs. 2.6.12-rc5-mm2


-- wli

Index: mm2-2.6.12-rc5/arch/sparc/Kconfig
===================================================================
--- mm2-2.6.12-rc5.orig/arch/sparc/Kconfig	2005-06-06 13:45:32.000000000 -0700
+++ mm2-2.6.12-rc5/arch/sparc/Kconfig	2005-06-06 16:08:36.859702935 -0700
@@ -264,7 +264,11 @@
 	  want to run SunOS binaries on an Ultra you must also say Y to
 	  "Kernel support for 32-bit a.out binaries" above.
 
-source "drivers/parport/Kconfig"
+source "mm/Kconfig"
+
+endmenu
+
+source "drivers/Kconfig"
 
 config PRINTER
 	tristate "Parallel printer support"
@@ -291,41 +295,10 @@
 	  If you have more than 8 printers, you need to increase the LP_NO
 	  macro in lp.c and the PARPORT_MAX macro in parport.h.
 
-source "mm/Kconfig"
-
-endmenu
-
-source "drivers/base/Kconfig"
-
-source "drivers/video/Kconfig"
-
-source "drivers/mtd/Kconfig"
-
-source "drivers/serial/Kconfig"
-
 if !SUN4
 source "drivers/sbus/char/Kconfig"
 endif
 
-source "drivers/block/Kconfig"
-
-# Don't frighten a common SBus user
-if PCI
-
-source "drivers/ide/Kconfig"
-
-endif
-
-source "drivers/isdn/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/fc4/Kconfig"
-
-source "drivers/md/Kconfig"
-
-source "net/Kconfig"
-
 # This one must be before the filesystem configs. -DaveM
 
 menu "Unix98 PTY support"
@@ -374,18 +347,8 @@
 
 endmenu
 
-source "drivers/input/Kconfig"
-
 source "fs/Kconfig"
 
-source "sound/Kconfig"
-
-source "drivers/usb/Kconfig"
-
-source "drivers/infiniband/Kconfig"
-
-source "drivers/char/watchdog/Kconfig"
-
 source "arch/sparc/Kconfig.debug"
 
 source "security/Kconfig"

frv, v850: no defconfig's

[Adrian Bunk]

On Sat, May 07, 2005 at 03:20:02PM +0200, Jan Dittmer wrote:
>...
> - frv: still broken
>   Details: http://l4x.org/k/?d=3479
>...
> - v850: still broken
>   Details: http://l4x.org/k/?d=3497
> 
> Summary: 8 ok, 14 failed
> Link to this page: http://l4x.org/k/?diff[v1]=mm

@ David, Miles:
Could you add defconfig's?

They serve at least two purposes:
- give people a starting point for their kernel configuration
- allow simple cross-compile tests like the one Jan did

A defconfig isn't something special, it's simply one reasonable .config 
for this architecture.

> Jan

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[-mm patch] fix typo in arch/h8300/Kconfig.cpu

[Adrian Bunk]

On Sat, May 07, 2005 at 03:20:02PM +0200, Jan Dittmer wrote:
> 
> Well I built something like this now which I mail to myself,
> overlook and then going sent to lkml:
>...
> - h8300: still broken
>   Details: http://l4x.org/k/?d=3480
>...
> Link to this page: http://l4x.org/k/?diff[v1]=mm

Trivial fix below.

> Jan

cu
Adrian


<--  snip  -->


This patch fixes a trivial typo in introduced by 
make-each-arch-use-mm-kconfig.patch .

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.12-rc3-mm3-full/arch/h8300/Kconfig.cpu.old	2005-05-07 16:59:48.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/arch/h8300/Kconfig.cpu	2005-05-07 17:00:12.000000000 +0200
@@ -181,6 +181,6 @@
 	bool "Preemptible Kernel"
 	default n
 
-source "mm/Kconfig'
+source "mm/Kconfig"
 
 endmenu

Re: RFD: Kernel release numbering

[Ralf Baechle]

On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:

> >  Looking at the http://l4x.org/k/ site, it appears that all -mm versions
> >  have broken ARM support with the defconfig, while Linus kernels at least
> >  build fine.
> 
> It's very much in an arch maintainer's interest to make sure that
> cross-compilers are easily obtainable.  Any hints?

In theory.  In practice on some platforms we need special compiler patches
which will never be accepted into gcc upstream or are restricted to
particular versions of tools.  Building crosstools is tricky and yet it
seems every moron really has to toll it's own from his private mouldy
collection of patches.  The whole tools stuff has become very much a
battlefield of it's own.

  Ralf

Re: RFD: Kernel release numbering

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> 
>>30?  Try 310 changesets, in my netdev-2.6 pending queue.
> 
> 
> Note that I don't think a 2.6.<even> would have problems with things like 
> driver updates.

Nah, I agree with DaveJ -- there are definitely "dev" portions when it 
comes to driver updates.

Judging from recent posting from Bart, it looks like he has an evil plot 
to merge the IDE driver with libata.  libata will also eventually 
[perhaps with Bart's changes?] make the SCSI portion optional, as I have 
long promised.  And it's getting other new and destabilizing features.

There will be other changes in SCSI and block too, which want staging... 
  Some of the stuff I've been putting off until "2.7" will be re-thought 
into something that appears in the on-going 2.6 series.

If you don't have driver stability, you don't have a useful kernel...

	Jeff

Re: RFD: Kernel release numbering

[Nigel Cunningham]

Hi.

My first response is: this is a recipe for great confusion among users.

I'd far rather see things only make it into your tree when they've been
thoroughly tested (in -mm and prior to that). Following that strategy,
your tree could always be relied upon to be stable and -rcs would only
needed for dealing with the unforeseen interactions between otherwise
mature patches.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de

Re: RFD: Kernel release numbering

[Josh Boyer]

On Wed, 2005-03-02 at 14:21 -0800, Linus Torvalds wrote:
> It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
> kind of even/odd thing didn't _work_, the problems really were an issue of
> too big granularity making it hard for user and developers alike. So I see
> this as a tweak of the "let's drop the notion althogether for now"  
> decision, and just modify it to "even/odd is meaningful at all levels".

I like it, but what about important security fixes or mistakes like
2.6.8.1?  In those situations, would you release that kernel under the
next even number and skip the odd number?  Or would you release the fix
under an odd number and sorta throw off the "meaning"?

I'm not trying to be a pain, I'm really not.

josh

Re: RFD: Kernel release numbering

[Willy Tarreau]

Hi Linus,

For a long time, I've been hoping/asking for a more frequent stable/unstable
cycle, so clearly you can count my vote on this one (eventhough it might
count for close to zero). This is a very good step towards a better stability
IMHO.

However, I have a comment :

>  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
>    to it (timeframe: a month or two).
>  - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
>    several releases (timeframe: a year or two)
>  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>    the kernel to be a microkernel using a special message-passing version 
>    of Visual Basic. (timeframe: "we expect that he will be released from 
>    the mental institution in a decade or two").

I don't agree with you on this last one (not the fact that you don't want
an mk+mp+vb combination :-)). The VERSION number (in the makefile meaning of
the term) only gets updated every 10 years or so. So it does not need to
jump. PATCHLEVEL increments are rare enough to justify lots of breaking.
I certainly can imagine people laughing at your OS when you jump from v2.6.X
to v4.0.X, it will have a smell of slowaris (remember 2.6 - 2.7 - 7 - 8 that
confused everyone ?). On the other side, the openbsd numbering scheme is far
simpler to understand, and I sincerely think that we should enter 3.0 after
2.8. As a side note, I've always wondered why we would not swap odds and
evens, so that we can keep the same major number between devel and release
(eg: devel 2.8, release 2.9 ; not devel 2.9, release 3.0). Anyway, people
have got used to stay away from the '.0' releases of any product on the
planet.

Regards
Willy

Re: RFD: Kernel release numbering

[Matthew Frost]

--- Willy Tarreau <willy@w.ods.org> wrote:

> Hi Linus,
> 
> For a long time, I've been hoping/asking for a more frequent
> stable/unstable cycle, so clearly you can count my vote on this one 
> (eventhough it might count for close to zero). This is a very good step

> towards a better stability IMHO.
> 
> However, I have a comment :
> 
> >  - 2.6.<odd>: still a stable kernel, but accept bigger changes
> >    leading up to it (timeframe: a month or two).
> >  - 2.<odd>.x: aim for big changes that may destabilize the kernel for
> >    several releases (timeframe: a year or two)
> >  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and
> >    rewrote the kernel to be a microkernel using a special
> >    message-passing version  of Visual Basic. (timeframe: "we expect 
> >    that he will be released from the mental institution in a decade
or
> >    two").
> 
> I don't agree with you on this last one (not the fact that you don't
> want an mk+mp+vb combination :-)). The VERSION number (in the makefile
> meaning of the term) only gets updated every 10 years or so. So it does

> not need to jump. PATCHLEVEL increments are rare enough to justify lots

> of breaking.  I certainly can imagine people laughing at your OS when 
> you jump from v2.6.X to v4.0.X, it will have a smell of slowaris 
> (remember 2.6 - 2.7 - 7 - 8 that confused everyone ?). On the other 
> side, the openbsd numbering scheme is far simpler to understand, and I 
> sincerely think that we should enter 3.0 after 2.8.

I hate to point out the obvious to someone of longer standing, but
according to the current system, since we increment integrally, 2.10.0
would be the successor release to the 2.9.X dev series, unless you know
something about a severe and profound internals shakeup scheduled for 2.9
that we don't.  :)

OT, 3.0.0 is an even-numbered release, therefore stable.  So what do you
call the odd-numbered unstable series that produces it?  ;)

> As a side note, I've
> always wondered why we would not swap odds and evens, so that we can 
> keep the same major number between devel and release (eg: devel 2.8, 
> release 2.9 ; not devel 2.9, release 3.0). Anyway, people have got used

> to stay away from the '.0' releases of any product on the planet.
> 
> Regards
> Willy
> 

Matt

Yes, I have too much free time.

Re: RFD: Kernel release numbering

[Ryan Anderson]

On Thu, Mar 03, 2005 at 12:59:18AM -0800, Matthew Frost wrote:
> 
> OT, 3.0.0 is an even-numbered release, therefore stable.  So what do you
> call the odd-numbered unstable series that produces it?  ;)

3.-1.x

:)


-- 

Ryan Anderson
  sometimes Pug Majere

Re: RFD: Kernel release numbering

[Mark Gross]

On Wednesday 02 March 2005 14:21, Linus Torvalds wrote:
> This is an idea that has been brewing for some time: Andrew has mentioned
> it a couple of times, I've talked to some people about it, and today Davem
> sent a suggestion along similar lines to me for 2.6.12.
>
> Namely that we could adopt the even/odd numbering scheme that we used to
> do on a minor number basis, and instead of dropping it entirely like we
> did, we could have just moved it to the release number, as an indication
> of what was the intent of the release.
>
> The problem with major development trees like 2.4.x vs 2.5.x was that the
> release cycles were too long, and that people hated the back- and
> forward-porting. That said, it did serve a purpose - people kind of knew
> where they stood, even though we always ended up having to have big
> changes in the stable tree too, just to keep up with a changing landscape.
>
> So the suggestion on the table would be to go back to even/odd, but do it
> at the "micro-level" of single releases, rather than make it a two- or
> three-year release cycle.
>
> In this setup, all kernels would still be _stable_, in the sense that we
> don't anticipate any real breakage (if we end up having to rip up so much
> basic stuff that we have to break anything, we'd go back to the 2.7.x kind
> of numbering scheme). So we should fear odd releases, but track them, to
> make sure that they are good (if you don't track them, and problems won't
> be fixed in the even version either)
>
> But we'd basically have stricter concerns for an even release, and in
> particular the plan would be that the diff files would alternate between
> bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
> 2.6.11->12 release would be a "stability only" thing, and hopefully the
> diff file would be much smaller).
>
> We'd still do the -rcX candidates as we go along in either case, so as a
> user you wouldn't even _need_ to know, but the numbering would be a rough
> guide to intentions. Ie I'd expect that distributions would always try to
> base their stuff off a 2.6.<even> release.
>
> It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
> kind of even/odd thing didn't _work_, the problems really were an issue of
> too big granularity making it hard for user and developers alike. So I see
> this as a tweak of the "let's drop the notion althogether for now"
> decision, and just modify it to "even/odd is meaningful at all levels".
>
> In other words, we'd have an increasing level of instability with an odd
> release number, depending on how long-term the instability is.
>
>  - 2.6.<even>: even at all levels, aim for having had minimally intrusive
>    patches leading up to it (timeframe: a week or two)
>
> with the odd numbers going like:
>
>  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up
>    to it (timeframe: a month or two).
>  - 2.<odd>.x: aim for big changes that may destabilize the kernel for
>    several releases (timeframe: a year or two)
>  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>    the kernel to be a microkernel using a special message-passing version
>    of Visual Basic. (timeframe: "we expect that he will be released from
>    the mental institution in a decade or two").
>
> The reason I put a shorter timeframe on the "all-even" kernel is because I
> don't want developers to be too itchy and sitting on stuff for too long if
> they did something slightly bigger. In theory, the longer the better
> there, but in practice this release numbering is still nothing but a hint
> of the _intent_ of the developers - it's still not a guarantee of "we
> fixed all bugs", and anybody who expects that (and tries to avoid all odd
> release entirely) is just setting himself up for not testing - and thus
> bugs.
>
> Comments?


Why be so wishy washy?

You can't say all that good stuff and then end it with " in practice this 
release numbering is still nothing but a hint of the _intent_ of the 
developer" and expect this to work out for more than a couple of builds 
before things fall back to where they are today.

Keep the change sets for the even numbers bug fix and stability changes only.  

While your at it schedule a cut off rc number by which any moderately risky 
bug and stability changes are allowed into the even build cycle,  say RC2, 
after which only stability and bug fixes that are considered to be "safe" 
changes are accepted.

You could also consider using the RC2 rule for odd releases so that  there is 
plenty of time to hash out the bugs from the bigger changes.  Just reject big 
changes after RC2.  The developers will adjust and plan for that after a few 
releases.

Thrashing your users with regressions is a very bad thing.

--mgross

>
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: RFD: Kernel release numbering

[Jeff Garzik]

IMO too confusing.

And it exacerbates an on-going issue:  we are moving away from "release 
early, release often", as this proposal just pushes the list of pending 
stuff back even further.

Developers right now are sitting on big piles, and pushing that back 
even further means every odd release means you are creating a 
2.4.x/2.5.x backport situation every two releases.

To take a radical position on the other side, I would prefer a weekly 
snapshot as the release, staging invasive things in -mm.

And I think -mm is not enough, even.  We have to come up with new ways 
to manage this ever-increasing flow of data into our tree.

	Jeff

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> IMO too confusing.
>

2.6.even: bugfixes only
2.6.odd: bugfixes and features.

That doesn't even confuse me!

> Developers right now are sitting on big piles, and pushing that back 
> even further means every odd release means you are creating a 
> 2.4.x/2.5.x backport situation every two releases.

No, there is no backporting.  If you have a bug, fix it in 2.6.12-pre. 
There is no need to maintain that bugfix in your 2.6.13-candidate tree.

It's still a linear progression of kernel trees.  The only thing which
changes is the types of patches which we put into even releases.

Re: RFD: Kernel release numbering

[Jeff Garzik]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>IMO too confusing.
>>
> 
> 
> 2.6.even: bugfixes only
> 2.6.odd: bugfixes and features.
> 
> That doesn't even confuse me!
> 
> 
>>Developers right now are sitting on big piles, and pushing that back 
>>even further means every odd release means you are creating a 
>>2.4.x/2.5.x backport situation every two releases.
> 
> 
> No, there is no backporting.  If you have a bug, fix it in 2.6.12-pre. 
> There is no need to maintain that bugfix in your 2.6.13-candidate tree.

You are missing where the backporting is.

If the time between big merges increases, as with this proposal, then 
the distance between local dev trees and linux-2.6 increases.

With that distance, breakages like the 64-bit resource struct stuff 
become more painful.

I like my own "ongoing dev tree, ongoing stable tree" proposal a lot 
better.  But then, I'm biased :)

	Jeff

Re: RFD: Kernel release numbering

[David S. Miller]

On Wed, 02 Mar 2005 19:29:35 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> If the time between big merges increases, as with this proposal, then 
> the distance between local dev trees and linux-2.6 increases.
> 
> With that distance, breakages like the 64-bit resource struct stuff 
> become more painful.
> 
> I like my own "ongoing dev tree, ongoing stable tree" proposal a lot 
> better.  But then, I'm biased :)

The problem is people don't test until 2.6.whatever-final goes out.
Nothing will change that.

And the day Linus releases we always get a pile of "missing MODULE_EXPORT()"
type bug reports that are one liner fixes.  Those fixes will not be seen by
users until the next 2.6.x rev comes out and right now that takes months
which is rediculious for such simple fixes.

We're talking about a one week "calming" period to collect the brown paper
bag fixes for a 2.6.${even} release, that's all.

All this "I have to hold onto my backlog longer, WAHHH!" arguments are bogus
IMHO.  We're using a week of quiescence to fix the tree for users so they
are happy whilst we work on the 2.6.${odd} interesting stuff :-)

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 04:58:30PM -0800, David S. Miller wrote:

 > The problem is people don't test until 2.6.whatever-final goes out.
 > Nothing will change that.
 > 
 > And the day Linus releases we always get a pile of "missing MODULE_EXPORT()"
 > type bug reports that are one liner fixes.  Those fixes will not be seen by
 > users until the next 2.6.x rev comes out and right now that takes months
 > which is rediculious for such simple fixes.

So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?
Apart from needing to do the 2.6.8.1 -> 2.6.8 -> 2.6.9 transition 
which confused some people, it seemed to be easily understood for what it was,
and solved the same problem as this new proposal.

		Dave

Re: RFD: Kernel release numbering

[Andrew Morton]

Dave Jones <davej@redhat.com> wrote:
>
> So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?

That's an alternative, of course.

But that _is_ a branch, and does need active forward- and (mainly)
backward-porting work.

There's nothing wrong with it per-se, but it becomes a "stabilised version
of the kernel.org tree" or even a "production version of the kernel.org
tree".  In other words it's somewhere on the line between the mainline
kernel.org tree and a distribution.  How far along that line should it
be positioned?

Re: RFD: Kernel release numbering

[Dave Jones]

On Wed, Mar 02, 2005 at 05:20:49PM -0800, Andrew Morton wrote:
 > Dave Jones <davej@redhat.com> wrote:
 > >
 > > So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?
 > 
 > That's an alternative, of course.
 > 
 > But that _is_ a branch, and does need active forward- and (mainly)
 > backward-porting work.
 > 
 > There's nothing wrong with it per-se, but it becomes a "stabilised version
 > of the kernel.org tree" or even a "production version of the kernel.org
 > tree".  In other words it's somewhere on the line between the mainline
 > kernel.org tree and a distribution.  How far along that line should it
 > be positioned?

In an ideal world, we'd see a single 'y' release of 2.6.x.y, but if x+1 takes
too long to be released, bits of x+1 should also appear in x.y+1
The only question in my mind is 'how critical does a bug have to be to
justify a .y release.  Once a new 'x' release comes out, the previous x.y
would likely no longer get any further fixes (unless someone decides the
new 'x' sucked so bad).

Linus using bitkeeper should actually remove most of the pain from this
multiple branch thing though. If fixes alternatively get checked into x.y
and new development goes into x+1, x+1 could do a daily pull of x.y
Thus saving the having to check in fixes to two seperate branches.
(which really really sucks under some SCMs).

		Dave

Re: RFD: Kernel release numbering

[Andries Brouwer]

Ha - a nice big thread. Issues include trivial fixes, testing,
and API stability.

-----
About trivial fixes:
davem: the day Linus releases we always get a pile of "missing MODULE_EXPORT()"
       type bug reports that are one liner fixes.
davej: So what was broken with the 2.6.8.1 type of release ?
akpm: But that _is_ a branch

I think we all like the 2.6.8.1 model.

davej: The only question in my mind is 'how critical does a bug have to be
       to justify a .y release'.

I think that is the wrong question. The question should be 'how trivial
should a fix be to be admissible in a .y release'. If something is important
but nonobvious, it should cause earlier release of 2.6.x+1.
No regressions in 2.6.x.y.

-----
About testing: users do not test p.q.r-suffix, they just test p.q.r
Solution: Release early, release often. No silly odd/even games.
jgarzik: I would prefer a weekly snapshot as the release

-----
API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
the guarantee that user-visible APIs do not change. That goal
has disappeared, meaning that anything might break when one
upgrades from 2.6.14 to 2.6.16.
This is one of the big disadvantages of the new 2.6 way.

-----
A separate twig is that of when to call a release 'stable'.
Since there is no good way to predict, the solution is 'wait and see'.
'Stable' also depends on the type of use. It is easier to leave
construction of stable kernels to separate people and trees.
With some delay they can have the benefit of hindsight.

Andries

Re: RFD: Kernel release numbering

[Krzysztof Halasa]

Andries Brouwer <aebr@win.tue.nl> writes:

> API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
> the guarantee that user-visible APIs do not change. That goal
> has disappeared, meaning that anything might break when one
> upgrades from 2.6.14 to 2.6.16.

Both 2.4 and 2.6 are IMHO similar. There were API changes in 2.4,
and in 2.6 they should be discouraged exactly as in 2.4.
-- 
Krzysztof Halasa

Re: RFD: Kernel release numbering

[Andrew Morton]

Andries Brouwer <aebr@win.tue.nl> wrote:
>
> API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
>  the guarantee that user-visible APIs do not change. That goal
>  has disappeared, meaning that anything might break when one
>  upgrades from 2.6.14 to 2.6.16.
>  This is one of the big disadvantages of the new 2.6 way.

It depends on what you call a "user visible API".

Changes which are visible to userspace are treated with great caution
nowadays[*].  I keep on rejecting patches...

Changes which are visible to third-party kernel modules are more
acceptable, but we're still fairly reluctant to make them.

So I think you exaggerate.  And I don't see that the problem which you
describe is inevitably a part of the "new 2.6 way".




[*] I don't know any details of the /proc incompatibility which davej
    mentions, and I'd like to.  That sounds like a screw-up.

Re: RFD: Kernel release numbering

[Dave Jones]

On Thu, Mar 03, 2005 at 01:09:01PM -0800, Andrew Morton wrote:

 > [*] I don't know any details of the /proc incompatibility which davej
 >     mentions, and I'd like to.  That sounds like a screw-up.

We changed the format of /proc/slabinfo.  Running slabtop threw up
an error message complaining that the format had changed.

It was a graceful failure, but a failure none-the-less.

Other failures have been somewhat more dramatic.
I know ipsec-tools, and alsa-lib have both caused pain
on at least one occasion after the last 2-3 kernel updates.

I was keeping track of these breakages, but I can't seem to
find the text file right now.  Bill, can you remember any
other cases worthy of mentioning ?

		Dave

Re: RFD: Kernel release numbering

[Jeff Garzik]

Dave Jones wrote:
> Other failures have been somewhat more dramatic.
> I know ipsec-tools, and alsa-lib have both caused pain
> on at least one occasion after the last 2-3 kernel updates.


alsa-lib is a special case.

alsa-lib exists so that it can mitigate changes between the kernel and 
userland.  If the kernel API changes, alsa-lib may need to be updated, 
but not all the apps using alsa-lib.

Someone needs to put alsa-lib updating on the list of stuff to do when 
updating the kernel...

	Jeff

Re: RFD: Kernel release numbering

[Bill Nottingham]

Dave Jones (davej@redhat.com) said: 
>  > [*] I don't know any details of the /proc incompatibility which davej
>  >     mentions, and I'd like to.  That sounds like a screw-up.
> 
> We changed the format of /proc/slabinfo.  Running slabtop threw up
> an error message complaining that the format had changed.
> 
> It was a graceful failure, but a failure none-the-less.
> 
> Other failures have been somewhat more dramatic.
> I know ipsec-tools, and alsa-lib have both caused pain
> on at least one occasion after the last 2-3 kernel updates.

The ones I remember were:

- alsa-lib, as mentioned
- ipsec-tools/openswan needed updating when the kernel changed
   to require forward SAs
- a old script on an earlier release needed fixed when usbdevfs finally
   went from being deprecated to dead

SELinux changed froom 2.6.early to 2.6.current as well, IIRC.

Bill

Re: RFD: Kernel release numbering

[Jaroslav Kysela]

On Thu, 3 Mar 2005, Dave Jones wrote:

> Other failures have been somewhat more dramatic.
> I know ipsec-tools, and alsa-lib have both caused pain
> on at least one occasion after the last 2-3 kernel updates.

alsa-lib: You mean the problem with the emu10k1 based soundcards from
Creative? It's because the multichannel devices were added and
reorganized. But the basic functionality (sound from front speakers and
analog capturing) should be preserved with all 1.0.x alsa-lib versions.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: RFD: Kernel release numbering

[Alan Cox]

On Iau, 2005-03-03 at 01:27, Dave Jones wrote:
> In an ideal world, we'd see a single 'y' release of 2.6.x.y, but if x+1 takes
> too long to be released, bits of x+1 should also appear in x.y+1
> The only question in my mind is 'how critical does a bug have to be to
> justify a .y release.  Once a new 'x' release comes out, the previous x.y
> would likely no longer get any further fixes (unless someone decides the
> new 'x' sucked so bad).

Do the statistics on rate of discovery of security problems (generally
low priority and by good guys/verification tools) and you are looking at
about x.y.8 or so assuming there are no 2.x.y.z releases for post
release howlers.

Re: RFD: Kernel release numbering

[Neil Brown]

On Wednesday March 2, akpm@osdl.org wrote:
> Dave Jones <davej@redhat.com> wrote:
> >
> > So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?
> 
> That's an alternative, of course.
> 
> But that _is_ a branch, and does need active forward- and (mainly)
> backward-porting work.
> 
> There's nothing wrong with it per-se, but it becomes a "stabilised version
> of the kernel.org tree" or even a "production version of the kernel.org
> tree".  In other words it's somewhere on the line between the mainline
> kernel.org tree and a distribution.  How far along that line should it
> be positioned?

I think there is a case for the "community" providing the most
"stable" kernel that it (reasonably) can without depending on
"distributions" to do that.

One reason is that (some) distributions are known to have released
kernels with quite broken and unreviewed patches, or with new
functionality that never ends up appearing in main-line for whatever
reason.   
Further, it would surely be useful for all distributions to have one
central place that 'stablising' patches appear so they can
pick-and-choose from them rather than each keeping their own
independent set.

For the kernel, I am the "distribution" for my employer and I choose
which kernel to use, with which patches.  I really don't want to hunt
around for all those stablisation patches, or sift through the patches
in 2.6.X+1-pre to find things to apply to 2.6.X.  I would be really
happy there was a central place where maintainers can put suitably
reviewed "important bug fix"es for recent releases, and from where
kernel maintainers for any distribution (official or not) could pull
them. 

Having said that, I am not in a position to offer my services to
maintain such a really-stable kernel branch, so I'll just cope with
whatever is provided.

NeilBrown

Re: RFD: Kernel release numbering

[Christoph Hellwig]

On Thu, Mar 03, 2005 at 12:59:20PM +1100, Neil Brown wrote:
> I think there is a case for the "community" providing the most
> "stable" kernel that it (reasonably) can without depending on
> "distributions" to do that.

The point is that it's happening anyway.  See Andres' -as tree which
is the basis for the Debian vendor kernel.  Getting that up to an
official status as 2.6.x.y would be very nice (and having it on
linux.bkbits.net)

Re: RFD: Kernel release numbering

[Paul Jackson]

Christoph wrote in reply to Neil:
> The point is that it's happening anyway.  See Andres' -as tree which
> is the basis for the Debian vendor kernel. 

Interesting.  We already have a pre-Linus tree, in Andrew's *-mm.
Currently, each distro adds its own set of patches, on top of some
version of a Linus tree.  If we had a blessed post-Linus tree, which the
2.6.<even>.y numbering fits, then we could unify this post-Linus tree
patching to some degree as well, to the general benefit of most everyone
involved.  A bit of holy penguin pee, a chosen spot in the official
numbering scheme, and a good choice of penguin prince as manager of this
release series should be enough to get this going.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401

Re: RFD: Kernel release numbering

[Alan Cox]

On Iau, 2005-03-03 at 03:10, Christoph Hellwig wrote:
> The point is that it's happening anyway.  See Andres' -as tree which
> is the basis for the Debian vendor kernel.  Getting that up to an
> official status as 2.6.x.y would be very nice (and having it on
> linux.bkbits.net)

IMHO it is nowhere near conservative enough (or at times complete
enough) to be a 2.6.x.y kernel. In some respects -ac is closer but it
also isn't as conservative as a real 2.6.x.y should be.

2.6.x.y needs several people to keep it tight and to ensure there is
always cover on a security fix. 

Re: RFD: Kernel release numbering

[Pavel Machek]

Hi!

> > The point is that it's happening anyway.  See Andres' -as tree which
> > is the basis for the Debian vendor kernel.  Getting that up to an
> > official status as 2.6.x.y would be very nice (and having it on
> > linux.bkbits.net)
> 
> IMHO it is nowhere near conservative enough (or at times complete
> enough) to be a 2.6.x.y kernel. In some respects -ac is closer but it
> also isn't as conservative as a real 2.6.x.y should be.
> 
> 2.6.x.y needs several people to keep it tight and to ensure there is
> always cover on a security fix. 

Eh?

Like you add security fix and then some formatting change to hide it?

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: RFD: Kernel release numbering

[Alan Cox]

On Sul, 2005-03-06 at 22:43, Pavel Machek wrote:
> > 2.6.x.y needs several people to keep it tight and to ensure there is
> > always cover on a security fix. 
> 
> Eh?
> 
> Like you add security fix and then some formatting change to hide it?

Cover has rather too many meanings I guess. Cover as in "there is
someone available to handle it"

Re: RFD: Kernel release numbering

[Chris Wright]

* Dave Jones (davej@redhat.com) wrote:
> So what was broken with the 2.6.8.1 type of 'hotfix kernel' release ?

I agree, I think that's useful and needed.  It's possible to get the
fixes committed to an effective branch in bk and pull that back into
mainline.  So at each new release the last release hotfix branch would
stop.  But does that solve a different problem?  I don't think it'll
increase people testing intended-stable versions.

thanks,
-chris

Re: RFD: Kernel release numbering

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20050302165830.0a74b85c.davem@davemloft.net> (at Wed, 2 Mar 2005 16:58:30 -0800), "David S. Miller" <davem@davemloft.net> says:

> All this "I have to hold onto my backlog longer, WAHHH!" arguments are bogus
> IMHO.  We're using a week of quiescence to fix the tree for users so they
> are happy whilst we work on the 2.6.${odd} interesting stuff :-)

I'm afarid people start waiting 2.6.${even} releases...

--yoshfuji

Re: RFD: Kernel release numbering

[David Lang]

On Wed, 2 Mar 2005, David S. Miller wrote:

> On Wed, 02 Mar 2005 19:29:35 -0500
> Jeff Garzik <jgarzik@pobox.com> wrote:
>
>> If the time between big merges increases, as with this proposal, then
>> the distance between local dev trees and linux-2.6 increases.
>>
>> With that distance, breakages like the 64-bit resource struct stuff
>> become more painful.
>>
>> I like my own "ongoing dev tree, ongoing stable tree" proposal a lot
>> better.  But then, I'm biased :)
>
> The problem is people don't test until 2.6.whatever-final goes out.
> Nothing will change that.
>
> And the day Linus releases we always get a pile of "missing MODULE_EXPORT()"
> type bug reports that are one liner fixes.  Those fixes will not be seen by
> users until the next 2.6.x rev comes out and right now that takes months
> which is rediculious for such simple fixes.
>
> We're talking about a one week "calming" period to collect the brown paper
> bag fixes for a 2.6.${even} release, that's all.
>
> All this "I have to hold onto my backlog longer, WAHHH!" arguments are bogus
> IMHO.  We're using a week of quiescence to fix the tree for users so they
> are happy whilst we work on the 2.6.${odd} interesting stuff :-)

I understand the desire and benifit to do this sort of fixing, but I 
really don't like extending the odd/even thing to other parts of the 
kernel version numbers

with 2.6.8 a different path was attempted with 2.6.8.1 couldn't we just 
use that numbering scheme (avoiding adding to the numbering confusion 
further) and plan on releasing a 2.6.11.1 next tuesday (or so) with the 
various paper-bag fixes?

If I understand bitkeeper properly Linus wouldn't even need to duplicate 
the patches, he should be able to fork his tree to do the paper-bag fixes 
in one fork while continueing development in the other one and then 
recombining them when either generates a release.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: RFD: Kernel release numbering

[Gene Heskett]

On Wednesday 02 March 2005 19:58, David S. Miller wrote:
>On Wed, 02 Mar 2005 19:29:35 -0500
>
>Jeff Garzik <jgarzik@pobox.com> wrote:
>
>The problem is people don't test until 2.6.whatever-final goes out.
>Nothing will change that.

Except more people who think like me.  I usually enjoy playing the 
canary, else I wouldn't do it.

More Canaries I say.  I build, and run till the next rc comes out 
almost every rc & I'm curently up on 2.6.11 for 5h:30m.  I've only 
got this one box thats fast enough to do that and still get anything 
else done too, so this is the workhorse.  I don't yelp about 
deprecation notices during the build, I figure you people have eyes 
too.

Basicly on my limited variety of hardware, I at least can play the 
part of the canary here, and have a couple of times when problems 
show up in less than a couple of days or during the build itself.

What you really need is a stronger plea for more people to go beat on 
the rc releases, but I fear thats never going to happen as long as 
there is nothing but the rc stuffs, and no -pre stuff for testing the 
-mm stuff a little wider.  Back in 2.4 days, even the -pre stuff was 
often stable enough for extended uptimes, and I mean that I ran

May  1  2003 vmlinuz-2.4.21-pre7 on that 7.3 box until Jan 21 2005.

Its now got a 2.4.29 final on it and:
 8:56pm  up 23 days,  8:00,  6 users,  load average: 2.12, 1.40, 1.14
 sailing along just as smoothly as ever since Feb 7.

Not without a reboot over that nearly 2 years of course, but the 
choice of when to do the reboot was mine in every case.  Here on this 
box, trying to play canary, uptimes are often less than a week, 
sometimes less than 24 hours, and that isn't anywhere near long 
enough to be able to say 'its stable'.  Stuff is IMO, being shoved 
out without an adequate amount of time to see what the 'canary' does.

If we could only get more people to 'bang on it, kick the tires etc', 
AND fix those sorts of problems that do show up in the next 
sequential rc, a lot of stuff like 2.6.8 could be headed off.
Note the caps on the word AND.  That bugfix in the next rc release 
seems to be broken when obviously needed fixes often have to go back 
to the head of the queue and work their way back to Linus.

So how DO you go about getting the tires kicked by more users?  I'm 
not sure what would work.

One doesn't have to be a code monkey to do this 'canary' scene as long 
as a bash script can be hacked up to do the majority of the work, I 
have a couple of them that basicly make a new kernel install a no 
brainer.  Often under 30 minutes to being rebooted to a new rc from 
going after the patch.

And I ramble, but this is my $0.02.  And probably about what its worth 
in the Grande Scheme of Things...

>And the day Linus releases we always get a pile of "missing
> MODULE_EXPORT()" type bug reports that are one liner fixes.  Those
> fixes will not be seen by users until the next 2.6.x rev comes out
> and right now that takes months which is rediculious for such
> simple fixes.

I agree.  Ditto for the 1394 fixes that have been upstream for at 
least a month, maybe more.  I haven't checked to see if kino can run 
my movie camera yet, if it can, then maybe it made it into 2.6.11.  
Otherwise I'll have to go nuke that dir in the drivers tree, and 
again grab the svn from the 1394 site and rebuild/reinstall.  
Provided the svn server is up, thats not a big deal here.  The point 
is that it is being tested, and it does work.

>We're talking about a one week "calming" period to collect the brown
> paper bag fixes for a 2.6.${even} release, that's all.
>
>All this "I have to hold onto my backlog longer, WAHHH!" arguments
> are bogus IMHO.  We're using a week of quiescence to fix the tree
> for users so they are happy whilst we work on the 2.6.${odd}
> interesting stuff :-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: RFD: Kernel release numbering

[Andrew Morton]

Gene Heskett <gene.heskett@verizon.net> wrote:
>
> Ditto for the 1394 fixes that have been upstream for at 
>  least a month, maybe more. 

-mm always holds the latest 1394 tree.  So you can run -mm, or just snarf
bk-ieee1394.patch from the broken-out directory.

Re: RFD: Kernel release numbering

[Gene Heskett]

On Wednesday 02 March 2005 22:17, Andrew Morton wrote:
>Gene Heskett <gene.heskett@verizon.net> wrote:
>> Ditto for the 1394 fixes that have been upstream for at
>>  least a month, maybe more.
>
>-mm always holds the latest 1394 tree.  So you can run -mm, or just
> snarf bk-ieee1394.patch from the broken-out directory.
>
Thanks Andrew.  If this is the same as I pulled from svn 2 weeks ago, 
it does need to be pushed on down the line.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: RFD: Kernel release numbering

[Andrew James Wade]

On March 2, 2005 09:14 pm, Gene Heskett wrote:
> One doesn't have to be a code monkey to do this 'canary' scene as long 
> as a bash script can be hacked up to do the majority of the work, I 
> have a couple of them that basicly make a new kernel install a no 
> brainer.  Often under 30 minutes to being rebooted to a new rc from 
> going after the patch.

I'm a casual user, and I'm happy to bang on the latest (-mm) kernels
so long as my data doesn't get corrupted. But the process of
downloading, patching, configuring, compiling, and installing a new
kernel is a bit of a pain, requiring user intervention a number of
times. It's enough that I don't update very often.

I've just done a bit of looking for scripts to automate the process of
installing a new kernel, and I haven't come up with much of much. So
right now I'm writing my own. If there are tools to help automate this
they need to be more prominent on www.kernel.org and
www.kernelnewbies.org, to make casual testing even easier.

Re: RFD: Kernel release numbering

[Jan Dittmer]

Andrew James Wade wrote:
> I've just done a bit of looking for scripts to automate the process of
> installing a new kernel, and I haven't come up with much of much. So
> right now I'm writing my own. If there are tools to help automate this
> they need to be more prominent on www.kernel.org and
> www.kernelnewbies.org, to make casual testing even easier.

Try ketchup from here: http://www.selenic.com/ketchup/
`ketchup 2.6-mm` for example will download and patch the newest 2.6-mm
kernel (also try ketchup 2.6-pre, ketchup 2.6-bk, ...).

Jan

-- 
http://l4x.org/k/

Re: RFD: Kernel release numbering

[Jeff Garzik]

David S. Miller wrote:
> On Wed, 02 Mar 2005 19:29:35 -0500
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> 
>>If the time between big merges increases, as with this proposal, then 
>>the distance between local dev trees and linux-2.6 increases.
>>
>>With that distance, breakages like the 64-bit resource struct stuff 
>>become more painful.
>>
>>I like my own "ongoing dev tree, ongoing stable tree" proposal a lot 
>>better.  But then, I'm biased :)
> 
> 
> The problem is people don't test until 2.6.whatever-final goes out.
> Nothing will change that.
> 
> And the day Linus releases we always get a pile of "missing MODULE_EXPORT()"
> type bug reports that are one liner fixes.  Those fixes will not be seen by
> users until the next 2.6.x rev comes out and right now that takes months
> which is rediculious for such simple fixes.
> 
> We're talking about a one week "calming" period to collect the brown paper
> bag fixes for a 2.6.${even} release, that's all.

If we want a calming period, we need to do development like 2.4.x is 
done today.  It's sane, understandable and it works.

2.6.x-pre: bugfixes and features
2.6.x-rc: bugfixes only


> All this "I have to hold onto my backlog longer, WAHHH!" arguments are bogus
> IMHO.  We're using a week of quiescence to fix the tree for users so they
> are happy whilst we work on the 2.6.${odd} interesting stuff :-)

If you think it will be only a week, you're deluding yourself.  It will 
stretch out to a month or longer, and the backlog problems will be real.

A calming period is fine.  But this even/odd mess is just silly.

	Jeff

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Wed, 2 Mar 2005, Jeff Garzik wrote:
> 
> If we want a calming period, we need to do development like 2.4.x is 
> done today.  It's sane, understandable and it works.

No. It's insane, and the only reason it works is that 2.4.x is a totally
different animal. Namely it doesn't have the kind of active development AT
ALL any more. It _only_ has the "even" number kind of things, and quite 
frankly, even those are a lot less than 2.6.x has.

> 2.6.x-pre: bugfixes and features
> 2.6.x-rc: bugfixes only

And the reason it does _not_ work is that all the people we want testing 
sure as _hell_ won't be testing -rc versions.

That's the whole point here, at least to me. I want to have people test 
things out, but it doesn't matter how many -rc kernels I'd do, it just 
won't happen. It's not a "real release".

In contrast, making it a real release, and making it clear that it's a 
release in its own right, might actually get people to use it. 

Might. Maybe.

			Linus

Re: RFD: Kernel release numbering

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> 
>>If we want a calming period, we need to do development like 2.4.x is 
>>done today.  It's sane, understandable and it works.
> 
> 
> No. It's insane, and the only reason it works is that 2.4.x is a totally
> different animal. Namely it doesn't have the kind of active development AT
> ALL any more. It _only_ has the "even" number kind of things, and quite 
> frankly, even those are a lot less than 2.6.x has.
> 
> 
>>2.6.x-pre: bugfixes and features
>>2.6.x-rc: bugfixes only
> 
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.
> 
> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".

People don't test 2.6-rc releases because they know they are not 
"release candidate, with only bug fixes" releases, which is how the rest 
of the world interprets the phrase.

Making them official releases in the even/odd manner is what neilb 
implies.  You'll just be diminishing the value of releases.  A "real 
release" won't be a real release anymore.  You're just renaming the -rc 
that isn't really an -rc.

	Jeff

Re: RFD: Kernel release numbering

[David S. Miller]

On Wed, 02 Mar 2005 22:40:57 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> People don't test 2.6-rc releases because they know they are not 
> "release candidate, with only bug fixes" releases, which is how the rest 
> of the world interprets the phrase.

That's not %100 true.  No matter what -rc* really is, people perceive
it to be something based upon it's name and whether or not it is an
official release.  As far as I can see it's %95 perception vs. reality.
And IT IS part of the reason the -rc's are not as good as they could be.

Re: RFD: Kernel release numbering

[Jeff Garzik]

David S. Miller wrote:
> On Wed, 02 Mar 2005 22:40:57 -0500
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> 
>>People don't test 2.6-rc releases because they know they are not 
>>"release candidate, with only bug fixes" releases, which is how the rest 
>>of the world interprets the phrase.
> 
> 
> That's not %100 true.  No matter what -rc* really is, people perceive
> it to be something based upon it's name and whether or not it is an
> official release.  As far as I can see it's %95 perception vs. reality.
> And IT IS part of the reason the -rc's are not as good as they could be.

The reasons -rcs are not as good as they could be is that they include 
more than just bug fixes.  Users are discouraged from testing because 
they must scan LKML, or guess, which -rc that Linus/Andrew started 
getting serious about "bugfixes only."

With the -pre/-rc scheme, it's clear to users.

With the even/odd scheme, you just devalue releases.  Previously, all 
releases were worthy of testing and use.  Now, half of them aren't.

	Jeff

Re: RFD: Kernel release numbering

[Jeff Garzik]

If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is 
preferable to even/odd.

Just create a 2.6.X repo at each release.  For bug fixes to 2.6.X, 
commit to this repo, then pull into linux-2.6.  For everything else, 
pull straight into linux-2.6.

The linux-2.6 repo would be upstream, and linux-2.6.X repo would be 
where bugfix-only releases come from.

	Jeff

Re: RFD: Kernel release numbering

[David S. Miller]

On Wed, 02 Mar 2005 23:46:22 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is 
> preferable to even/odd.

All of these arguments are circular.  If people think that even/odd
will devalue odd releases, guess what 2.6.x.y will do?  By that line
of reasoning nobody will test 2.6.x just the same as they aren't
testing 2.6.x-rc* right now.

I think they will test the odd releases, because as a real release
they will get slashdot/lwn.net/etc. announcements.

That's one of the major things the -rc's don't get.  Maybe it gets
a reference in lwn.net's weekly kernel article, but mostly kernel
geeks read those and that's not who we want testing -rc's (such
geeks already are doing so).

It has to be a "real" release.  That does have an impact.  However,
I am ambivalent about how to make them real.  Even/odd, 2.6.x.y,
either is fine with me.

Re: RFD: Kernel release numbering

[Russell Miller]

On Wednesday 02 March 2005 20:58, David S. Miller wrote:

> That's one of the major things the -rc's don't get.  Maybe it gets
> a reference in lwn.net's weekly kernel article, but mostly kernel
> geeks read those and that's not who we want testing -rc's (such
> geeks already are doing so).
>
How do you know that they won't stop the announcements if this change is made?

--Russell

-- 

Russell Miller - rmiller@duskglow.com - Agoura, CA

Re: RFD: Kernel release numbering

[David S. Miller]

On Wed, 2 Mar 2005 21:08:07 -0800
Russell Miller <rmiller@duskglow.com> wrote:

> How do you know that they won't stop the announcements if this change is made?

Nobody knows such things for sure, let's test it and find out :-)

Re: RFD: Kernel release numbering

[Jeff Garzik]

David S. Miller wrote:
> On Wed, 02 Mar 2005 23:46:22 -0500
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> 
>>If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is 
>>preferable to even/odd.
> 
> 
> All of these arguments are circular.  If people think that even/odd
> will devalue odd releases, guess what 2.6.x.y will do?  By that line
> of reasoning nobody will test 2.6.x just the same as they aren't
> testing 2.6.x-rc* right now.

even/odd means that certain releases (even ones) are more magical than 
others.  That's weird, since users aren't used to that sort of thing in 
any other project.

2.6.x.y and 2.6.x-rc [where rc == serious bugfixes only!] are 
understandable to users, because they have seen that sort of thing before.

Users _aren't_ fooled by naming games.  The current 2.6-rc proves that.


> I think they will test the odd releases, because as a real release
> they will get slashdot/lwn.net/etc. announcements.
> 
> That's one of the major things the -rc's don't get.  Maybe it gets
> a reference in lwn.net's weekly kernel article, but mostly kernel
> geeks read those and that's not who we want testing -rc's (such
> geeks already are doing so).

LWN, Slashdot and others will not be fooled though :)  They will note 
that release 2.6.<odd> is not a real release.


> It has to be a "real" release.  That does have an impact.  However,
> I am ambivalent about how to make them real.  Even/odd, 2.6.x.y,
> either is fine with me.

2.6.x.y has a very real engineering benefit:  it becomes a stable 
release branch.  That will encourage even more users to test it, over 
and above a simple release naming change.

Users have been clamoring for a stable release branch in any case, as 
you see from comments about Alan's -ac and an LKML user's -as kernels.

	Jeff

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 02:52:21AM -0500, Jeff Garzik wrote:
> 2.6.x.y has a very real engineering benefit:  it becomes a stable 
> release branch.  That will encourage even more users to test it, over 
> and above a simple release naming change.
> 
> Users have been clamoring for a stable release branch in any case, as 
> you see from comments about Alan's -ac and an LKML user's -as kernels.

Sure they've been asking for it, but I think they really don't know what
it entails.  Look at all of the "non-stable" type patches in the -ac and
as tree.  There's a lot of stuff in there.  It's a slippery slope down
when trying to say, "I'm only going to accept bug fixes." 

Bug fixes for what?  Kernel api changes that fix bugs?  That's pretty
big.  Some driver fixes, but not others?  Driver fixes that are in the
middle of bigger, subsystem reworks as a series of patches?  All of this
currently happens today in the main tree in a semi-cohesive manner.  To
try to split it out is a very difficult task.

So, while I like the _idea_ of the 2.6.x.y type releases, having those
releases contain anything but a handful of patches will quickly get
quite messy.

Not to mention the issue of the need for me as a maintainer to mark
"bugfix only" specific patches and pull them out and submit them
separately.  Due to api changes, and all sorts of other issues, that can
get to be a difficult job in itself.

Personally, I like the current, "test it all in -mm and then forward the
good bits to Linus" mode we are operating in.  My only suggestion would
to possibly speed up the release cycle a bit faster than every two
months, like we currently are on.  Once a month perhaps?  That was how
we were working at the beginning of 2.6, and it seemed like the backlog
was much smaller then.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Jeff Garzik]

Greg KH wrote:
> Sure they've been asking for it, but I think they really don't know what
> it entails.  Look at all of the "non-stable" type patches in the -ac and
> as tree.  There's a lot of stuff in there.  It's a slippery slope down
> when trying to say, "I'm only going to accept bug fixes." 

We have all these problems precisely because _nobody_ is saying "I'm 
only going to accept bug fixes".  We _need_ some amount of release 
engineering.  Right now we basically have none.


> Bug fixes for what?  Kernel api changes that fix bugs?  That's pretty
> big.  Some driver fixes, but not others?  Driver fixes that are in the
> middle of bigger, subsystem reworks as a series of patches?  All of this
> currently happens today in the main tree in a semi-cohesive manner.  To
> try to split it out is a very difficult task.

Easiest to answer with a concrete example:

Linux 2.6.11 is released.  Linus then does a
	bk clone linux-2.6 linux-2.6.11

Bug fixes that
(a) 2.6.11 users really should have, or
(b) Linus/Andrew feels are important, or
(c) a subsystem maintainer feels are important [and does the work to 
split out the fixes]

go into linux-2.6.11 repo, and then is pulled into linux-2.6 repo.

All other changes go into linux-2.6.

There's no need to over-think or over-work this.  The goal is to provide 
a stable 2.6.11 for users, until 2.6.12 is available.

My prediction is that several patches will flow into the linux-2.6.11 
repo a week or so after a release, and then the flow will die off to a 
trickle.  Subsystem maintainers that care can submit patches/BK-pulls 
for the stable release if they so desire.

Only important "oh shit, that should have been in 2.6.11" bug fixes need 
apply.  Bug fixes for reworks, API changes, etc. are -not- applicable to 
linux-2.6.11 repo.

Since BitKeeper can handle nicely a
	cd linux-2.6
	bk pull ../linux-2.6.11
there is no duplication of bug fixes.

	Jeff

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 03:27:42AM -0500, Jeff Garzik wrote:
> Greg KH wrote:
> >Sure they've been asking for it, but I think they really don't know what
> >it entails.  Look at all of the "non-stable" type patches in the -ac and
> >as tree.  There's a lot of stuff in there.  It's a slippery slope down
> >when trying to say, "I'm only going to accept bug fixes." 
> 
> We have all these problems precisely because _nobody_ is saying "I'm 
> only going to accept bug fixes".  We _need_ some amount of release 
> engineering.  Right now we basically have none.

Linus says that in -rc releases, are you not paying attention to that?
(yes, I know you are...)

> >Bug fixes for what?  Kernel api changes that fix bugs?  That's pretty
> >big.  Some driver fixes, but not others?  Driver fixes that are in the
> >middle of bigger, subsystem reworks as a series of patches?  All of this
> >currently happens today in the main tree in a semi-cohesive manner.  To
> >try to split it out is a very difficult task.
> 
> Easiest to answer with a concrete example:
> 
> Linux 2.6.11 is released.  Linus then does a
> 	bk clone linux-2.6 linux-2.6.11
> 
> Bug fixes that
> (a) 2.6.11 users really should have, or
> (b) Linus/Andrew feels are important, or
> (c) a subsystem maintainer feels are important [and does the work to 
> split out the fixes]
> 
> go into linux-2.6.11 repo, and then is pulled into linux-2.6 repo.
> 
> All other changes go into linux-2.6.
> 
> There's no need to over-think or over-work this.  The goal is to provide 
> a stable 2.6.11 for users, until 2.6.12 is available.

Will Linus start accepting 2.6.12 patches right after 2.6.10 is out?

> My prediction is that several patches will flow into the linux-2.6.11 
> repo a week or so after a release, and then the flow will die off to a 
> trickle.  Subsystem maintainers that care can submit patches/BK-pulls 
> for the stable release if they so desire.
> 
> Only important "oh shit, that should have been in 2.6.11" bug fixes need 
> apply.  Bug fixes for reworks, API changes, etc. are -not- applicable to 
> linux-2.6.11 repo.
> 
> Since BitKeeper can handle nicely a
> 	cd linux-2.6
> 	bk pull ../linux-2.6.11
> there is no duplication of bug fixes.

That sounds very sane to me, I can live with it.

The main point is, will people really test the 2.6.odd releases to help
us out in making this new scheme work.  If so, I'm all for it.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Jeff Garzik]

Greg KH wrote:
> On Thu, Mar 03, 2005 at 03:27:42AM -0500, Jeff Garzik wrote:
> 
>>Greg KH wrote:
>>
>>>Sure they've been asking for it, but I think they really don't know what
>>>it entails.  Look at all of the "non-stable" type patches in the -ac and
>>>as tree.  There's a lot of stuff in there.  It's a slippery slope down
>>>when trying to say, "I'm only going to accept bug fixes." 
>>
>>We have all these problems precisely because _nobody_ is saying "I'm 
>>only going to accept bug fixes".  We _need_ some amount of release 
>>engineering.  Right now we basically have none.
> 
> 
> Linus says that in -rc releases, are you not paying attention to that?
> (yes, I know you are...)

The point there is that users, who are conditioned in the software world 
to think "release candidate means bug fixes only" come to Linux only to 
learn that

-rc1 isn't a release candidate, it's just the first public test kernel.
-rc2 isn't a release candidate, it's just a signal to kernel developers 
to slow down
-rc3 may be a release candidate, unless Linus does something typical and 
merges non-bug fixes.
-rc4 is probably a release candidate
...

The users ARE paying attention to this -- this is precisely why they do 
not take -rc releases seriously.


>>>Bug fixes for what?  Kernel api changes that fix bugs?  That's pretty
>>>big.  Some driver fixes, but not others?  Driver fixes that are in the
>>>middle of bigger, subsystem reworks as a series of patches?  All of this
>>>currently happens today in the main tree in a semi-cohesive manner.  To
>>>try to split it out is a very difficult task.
>>
>>Easiest to answer with a concrete example:
>>
>>Linux 2.6.11 is released.  Linus then does a
>>	bk clone linux-2.6 linux-2.6.11
>>
>>Bug fixes that
>>(a) 2.6.11 users really should have, or
>>(b) Linus/Andrew feels are important, or
>>(c) a subsystem maintainer feels are important [and does the work to 
>>split out the fixes]
>>
>>go into linux-2.6.11 repo, and then is pulled into linux-2.6 repo.
>>
>>All other changes go into linux-2.6.
>>
>>There's no need to over-think or over-work this.  The goal is to provide 
>>a stable 2.6.11 for users, until 2.6.12 is available.
> 
> 
> Will Linus start accepting 2.6.12 patches right after 2.6.10 is out?
> 
> 
>>My prediction is that several patches will flow into the linux-2.6.11 
>>repo a week or so after a release, and then the flow will die off to a 
>>trickle.  Subsystem maintainers that care can submit patches/BK-pulls 
>>for the stable release if they so desire.
>>
>>Only important "oh shit, that should have been in 2.6.11" bug fixes need 
>>apply.  Bug fixes for reworks, API changes, etc. are -not- applicable to 
>>linux-2.6.11 repo.
>>
>>Since BitKeeper can handle nicely a
>>	cd linux-2.6
>>	bk pull ../linux-2.6.11
>>there is no duplication of bug fixes.
> 
> 
> That sounds very sane to me, I can live with it.
> 
> The main point is, will people really test the 2.6.odd releases to help
> us out in making this new scheme work.  If so, I'm all for it.

2.6.X.Y is a bit different from 2.6.{odd|even}.

With 2.6.X.Y, you are not limited to single bugfix release.

With 2.6.X.Y, the kernel only gets successively more stable and 
bugfixed, without having to worry about new breakages.

With 2.6.X.Y, you are giving the users a familiar paradigm for 
understanding the release mechanism.

With 2.6.X.Y, all releases are "real releases."  You're not tricking the 
users with semantic games.

So there is a strong incentive not only to test... but to _use_ our 
releases.

	Jeff

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> We have all these problems precisely because _nobody_ is saying "I'm 
>  only going to accept bug fixes".  We _need_ some amount of release 
>  engineering.  Right now we basically have none.

Sorry Jeff, but that's crap.  Go look at the commits list.  Every single
patch which has gone into the tree for the past two weeks is a bugfix, I
think.

The most recent non-fix I see is

ChangeSet 1.2044, 2005/02/22 20:44:37-05:00, romieu@fr.zoreil.com

 	[PATCH] r8169: removal of unused #define
 	
 	Removal of unused #define
 	
 	Signed-off-by: Jon Mason <jdmason@us.ibm.com>
 	Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
 	Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

So pphhhfftt ;)


And the most recent non-trivial not-completely-a-bugfix patch I see
is "USB: Add ioctls to ub", from Feb 17.  And even that's an outlier.

Re: RFD: Kernel release numbering

[Jeff Garzik]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>We have all these problems precisely because _nobody_ is saying "I'm 
>> only going to accept bug fixes".  We _need_ some amount of release 
>> engineering.  Right now we basically have none.
> 
> 
> Sorry Jeff, but that's crap.  Go look at the commits list.  Every single
> patch which has gone into the tree for the past two weeks is a bugfix, I
> think.

It's an an exaggeration, but what do users that don't follow daily 
kernel development see?

"oh, somewhere between -rc1 and -rc5 they got serious about taking only 
bugfixes.  Andrew Morton says it was the past few weeks... what -rc is 
that?"

	Jeff

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Jeff Garzik wrote:
>
> Greg KH wrote:
> > Sure they've been asking for it, but I think they really don't know what
> > it entails.  Look at all of the "non-stable" type patches in the -ac and
> > as tree.  There's a lot of stuff in there.  It's a slippery slope down
> > when trying to say, "I'm only going to accept bug fixes." 
> 
> We have all these problems precisely because _nobody_ is saying "I'm 
> only going to accept bug fixes".  We _need_ some amount of release 
> engineering.  Right now we basically have none.

I agree that this is one of the main problems.

But look at how to solve it. The _logical_ solution is to have a third
line of defense: we have the -mm trees (wild and wacky patches), and we
have my tree (hopefully not wacky any more), and it would be good to have
a third level tree (which I'm just not interested in, because that one
doesn't do any development any more) which only takes the "so totally not
wild that it's really boring" patches.

In fact, if somebody maintained that kind of tree, especially in BK, it 
would be trivial for me to just pull from it every once in a while (like 
ever _day_ if necessary). But for that to work, then that tree would have 
to be about so _obviously_ not wild patches that it's a no-brainer.

So what's the problem with this approach? It would seem to make everybody
happy: it would reduce my load, it would give people the alternate "2.6.x
base kernel plus fixes only" parallell track, and it would _not_ have the 
testability issue (because I think a lot of people would be happy to test 
that tree, and if it was always based on the last 2.6.x release, there 
would be no issues.

Anybody?

I'll tell you what the problem is: I don't think you'll find anybody to do
the parallell "only trivial patches" tree. They'll go crazy in a couple of
weeks. Why? Because it's a _damn_ hard problem. Where do you draw the
line? What's an acceptable patch? And if you get it wrong, people will
complain _very_ loudly, since by now you've "promised" them a kernel that
is better than the mainline. In other words: there's almost zero glory,
there are no interesting problems, and there will absolutely be people who 
claim that you're a dick-head and worse, probably on a weekly basis.

That said, I think in theory it's a great idea. It might even be 
technically feasible if there was some hard technical criteria for each 
patch that gets accepted, so that you don't have the burn-out problem. 

So let's loook at how we could set that up. We need:

 - a sucker who wants to do this, or a company that pays for somebody good 
   to do this (and remember: "good" here doesn't necessarily have to mean 
   technical genius, it's about taking abuse and being stable). The whole 
   setup should be such that there can never be any question about the 
   patches for _other_ reasons (to avoid the sucker becoming a target for 
   abuse), so this person really to some degree would be fairly 
   mechanical.

   Don't make it automated, though. That just gets us down the path of 
   flaming about the scripts and automation. And I'm not claiming that we 
   should aim for somebody _stupid_, I'm just claiming that it takes a
   certain kind of person to do something that is not all that glamorous, 
   and that puts you in the spot.

   We don't ever want to have that spark of "wouldn't this be cool" in
   this project. 

 - some very _technical_ and objective rules on patches. And they should 
   limit the patches severely, so that people can never blame the sucker 
   who does the job. For example, I would suggest that "size" be one hard 
   technical rule. If the patch is more than 100 lines (with context) in
   size, it's not trivial any more. Really. Two big screenfuls (or four, 
   for people who still use the ISO-ANSI standard 80x24 vt100)

   Also, I'd suggest that a _hard_ rule (ie nobody can override it) would 
   also be that the problem causes an oops, a hang, or a real security
   problem that somebody can come up with an exploit for (ie no "there
   could be a two-instruction race" crap. Only "there is a race, and
   here's how you exploit it"). The exploit wouldn't need to be full code 
   that gets root, but an explanation of it, at least.

 - a vetting process. You'd have ten people, and five of them would have 
   to sign off on the patch, and even a single veto would shoot it down. 

   Again, this is really to protect the sucker, and make it possible to
   work: I don't think this can work with a creative person (everybody
   else calls me "flaky", and I much prefer that "creative" word, it sounds
   so much better), which I personally believe means that we don't _want_
   people like Alan, Andrea, Andrew etc etc that have historically maintained
   their own trees that sometimes have tried to do something like this.

 - Finally: this tree never has any history past the "last release". When
   a new kernel comes, the tree is frozen, and never to be touched again.

   If somebody _else_ wants to base things off this special "sucker tree", 
   and make a fourth level tree that is based on the _previous_ stable 
   tree, that's fine, but that's a separate process. He would be totally 
   free to do so, but the rule is that this particular maintenance program 
   _never_ gets stuck on an old kernel, like the vendor trees always are. 

   This is not a long-range tree, it would _purely_ be about one thing and
   one thing only: the last stable kernel. The people involved (sucker and 
   vetters all) would never have to remember two different trees, or care 
   about problems that aren't in the top-of-tree. Keep ti simple, and keep 
   the rules clear.

Does this mean that some patches would never go into this tree? Yes. It
would mean that patches that some people might feel very _strongly_ are
good patches would never ever show up in this tree, but on the other hand,
I can see this tree being useful regardless, and I think the lack of
flexibility in this case is actually the whole _point_ of the tree. The 
lack of flexibility is the very thing that makes this be the kind of base 
that anybody else can then hang their own patches on top of. There should 
never be a situation where "I'd like that tree, but I think xxxx was done 
wrong".

Might something like this make people happier? (I wrote "happy" rather
than "happier" at first, but let's face it, people are better at whining
than they are at being happy ;)

			Linus

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> 
> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.
> 
> Anybody?

Well, I'm one person who has said that this would be a very tough
problem to solve.  And hey, I like tough problems, so I'll volunteer to
start this.  If I burn out, I'll take the responsibility of finding
someone else to take it over.

I really like the rules you've outlined, that makes it almost possible
to achieve sanity.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Theodore Ts'o]

On Thu, Mar 03, 2005 at 08:43:53AM -0800, Greg KH wrote:
> On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> > 
> > So what's the problem with this approach? It would seem to make everybody
> > happy: it would reduce my load, it would give people the alternate "2.6.x
> > base kernel plus fixes only" parallell track, and it would _not_ have the 
> > testability issue (because I think a lot of people would be happy to test 
> > that tree, and if it was always based on the last 2.6.x release, there 
> > would be no issues.
> > 
> > Anybody?
> 
> Well, I'm one person who has said that this would be a very tough
> problem to solve.  And hey, I like tough problems, so I'll volunteer to
> start this.  If I burn out, I'll take the responsibility of finding
> someone else to take it over.

Ooh, a sucker!

Seriously, I think Linus's plan makes a lot of sense, as a scalable
way of maintaining a 2.6.x.y release strategy.

The other thing which would probably be useful to maintain would be a
list of "known regressions" yet to be fixed in 2.6.x.y, and to address
the somewhat disturbing assertions that sometimes regressions "light
up bugzilla" at distro's like Fedora, but don't get reflected back up
to LKML.  Maybe we could recruit some other sucker to maintain such a
list?  It wouldn't be a complete bug list, and it can be discarded
every time a new 2.6.x is released, which means it should be more
manageable than some previous attempts to maintain LK bug lists.

						- Ted

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 12:00:39PM -0500, Theodore Ts'o wrote:
> On Thu, Mar 03, 2005 at 08:43:53AM -0800, Greg KH wrote:
> > On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> > > 
> > > So what's the problem with this approach? It would seem to make everybody
> > > happy: it would reduce my load, it would give people the alternate "2.6.x
> > > base kernel plus fixes only" parallell track, and it would _not_ have the 
> > > testability issue (because I think a lot of people would be happy to test 
> > > that tree, and if it was always based on the last 2.6.x release, there 
> > > would be no issues.
> > > 
> > > Anybody?
> > 
> > Well, I'm one person who has said that this would be a very tough
> > problem to solve.  And hey, I like tough problems, so I'll volunteer to
> > start this.  If I burn out, I'll take the responsibility of finding
> > someone else to take it over.
> 
> Ooh, a sucker!

Two of us even :)

> Seriously, I think Linus's plan makes a lot of sense, as a scalable
> way of maintaining a 2.6.x.y release strategy.

I agree, and if Chris and I share the load, it might even make it a bit
more robust in that we can cover for each other when one is traveling,
etc.

> The other thing which would probably be useful to maintain would be a
> list of "known regressions" yet to be fixed in 2.6.x.y, and to address
> the somewhat disturbing assertions that sometimes regressions "light
> up bugzilla" at distro's like Fedora, but don't get reflected back up
> to LKML.  Maybe we could recruit some other sucker to maintain such a
> list?

That would be great, and any help from the distro bug-wranglers would be
appreciated.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Eric Gaumer]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

Greg KH wrote:
> On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
>
>>So what's the problem with this approach? It would seem to make everybody
>>happy: it would reduce my load, it would give people the alternate "2.6.x
>>base kernel plus fixes only" parallell track, and it would _not_ have the
>>testability issue (because I think a lot of people would be happy to test
>>that tree, and if it was always based on the last 2.6.x release, there
>>would be no issues.
>>
>>Anybody?
>
>
> Well, I'm one person who has said that this would be a very tough
> problem to solve.  And hey, I like tough problems, so I'll volunteer to
> start this.  If I burn out, I'll take the responsibility of finding
> someone else to take it over.
>
> I really like the rules you've outlined, that makes it almost possible
> to achieve sanity.
>

How does what Linus outlined differ from splitting to 2.7? Isn't it the same thing with just
a different versioning scheme? In the end we have a stable 2.6 tree. What's the difference
between the 2.6 development tree and 2.7.

All that aside... why not make the "sucker tree" a breeding ground for new kernel hackers.
I've been trying to get more involved with kernel development (as are others) but it's tough
because things change so rapidly that once you finally figure it out, it has changed. As the
kernel matures into new versions it's getting much harder for guys coming out of school to
figure out. Sure you have that exceptional individual but maybe you're committing genocide
in the end.

If someone like Greg could lead this band of gypsies then that would be great. Most of the
more experienced hackers don't want to slow pace and do all this boring work but people like
myself would be honored to "pay our dues". We would feel free to ask some questions and see
a slower pace so we can learn. If patches are small and truly only fix bugs then wouldn't
you say this would be possible? In fact one criteria could be that if we can't understand
just what exactly the patch fixes then it probably doesn't belong in this tree? It's a win -
win situation. End users are happy and we start a semi-structured training camp.


--
"Education is what remains after one has forgotten everything he learned in school."
	- Albert Einstein

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 09:04:43AM -0800, Eric Gaumer wrote:
> Greg KH wrote:
> >On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> >
> >>So what's the problem with this approach? It would seem to make everybody
> >>happy: it would reduce my load, it would give people the alternate "2.6.x
> >>base kernel plus fixes only" parallell track, and it would _not_ have the
> >>testability issue (because I think a lot of people would be happy to test
> >>that tree, and if it was always based on the last 2.6.x release, there
> >>would be no issues.
> >>
> >>Anybody?
> >
> >
> >Well, I'm one person who has said that this would be a very tough
> >problem to solve.  And hey, I like tough problems, so I'll volunteer to
> >start this.  If I burn out, I'll take the responsibility of finding
> >someone else to take it over.
> >
> >I really like the rules you've outlined, that makes it almost possible
> >to achieve sanity.
> >
> 
> How does what Linus outlined differ from splitting to 2.7?

- Each 2.6.x.y series would be abandanded after the next 2.6.x release
  came out.
- There would be no big development fork.

Those are two ways this differs.
 
> All that aside... why not make the "sucker tree" a breeding ground for new 
> kernel hackers.

Have you looked into the kernel-janitor project?  That's the best
"breeding" ground around for people who want to learn the kernel
development process.  I highly recommend that.

I don't think this "stable/bugfix" release series would be a good place
for new hackers, as most first bugfixes are of the janitorial type,
which would not be accepted into such a release tree.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Chris Friesen]

Linus Torvalds wrote:

> I'll tell you what the problem is: I don't think you'll find anybody to do
> the parallell "only trivial patches" tree.

Isn't this what -ac and -as effectively already are?

Chris

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 10:55:13AM -0600, Chris Friesen wrote:
> Linus Torvalds wrote:
> 
> >I'll tell you what the problem is: I don't think you'll find anybody to do
> >the parallell "only trivial patches" tree.
> 
> Isn't this what -ac and -as effectively already are?

Based on the patches in those trees, no :)

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Alan Cox]

On Iau, 2005-03-03 at 16:59, Greg KH wrote:
> On Thu, Mar 03, 2005 at 10:55:13AM -0600, Chris Friesen wrote:
> > Linus Torvalds wrote:
> > 
> > >I'll tell you what the problem is: I don't think you'll find anybody to do
> > >the parallell "only trivial patches" tree.
> > 
> > Isn't this what -ac and -as effectively already are?
> 
> Based on the patches in those trees, no :)

I've not found a much smaller set that isn't rootable, trivially DoSable
with published tools or leaves users with non-working hardware that got
pulled by Linus having a random pissy fit about pwc etc.

-ac is essentially base security fixes + working IDE locking + pwc +
fixes for the bugs everyone hit that needed fixing urgently. I consider
working locking on my storage essential because I like my data to still
be there.

-as is similar although it makes different choices about what matters.

Given 3 or 4 people it ought to be possible to make a much much tighter
patch set for this purpose.

Re: RFD: Kernel release numbering

[CaT]

On Thu, Mar 03, 2005 at 11:51:42PM +0000, Alan Cox wrote:
> -ac is essentially base security fixes + working IDE locking + pwc +
> fixes for the bugs everyone hit that needed fixing urgently. I consider
> working locking on my storage essential because I like my data to still
> be there.

Working IDE locking? Does this mean if I have 2 promise cards, a HD
on each card and I copy from one to the other it wont all blow up in my
face?

Please say yes. :)

-- 
    Red herrings strewn hither and yon.

Re: RFD: Kernel release numbering

[Alan Cox]

On Gwe, 2005-03-04 at 00:19, CaT wrote:
> Working IDE locking? Does this mean if I have 2 promise cards, a HD
> on each card and I copy from one to the other it wont all blow up in my
> face?

Depends on your PCI bus and also if the are on the same IRQ. In the same
IRQ case you may find 2.6.11 is a bit saner as Bartlomiej may have
sorted one of the IRQ masking problems now.

IDE locking (was: Re: RFD: Kernel release numbering)

[CaT]

On Fri, Mar 04, 2005 at 12:44:04AM +0000, Alan Cox wrote:
> On Gwe, 2005-03-04 at 00:19, CaT wrote:
> > Working IDE locking? Does this mean if I have 2 promise cards, a HD
> > on each card and I copy from one to the other it wont all blow up in my
> > face?
> 
> Depends on your PCI bus and also if the are on the same IRQ. In the same

Hmm. How can I check on this? What should I look for?

> IRQ case you may find 2.6.11 is a bit saner as Bartlomiej may have
> sorted one of the IRQ masking problems now.

/proc/interrupts reports different irqs for each ide device:

  5:    5018683          XT-PIC  ide4
 11:     167995          XT-PIC  ide2, eth0
 14:      39799          XT-PIC  ide0
 15:      10704          XT-PIC  ide1

The problems were weird. The fs I was copying from decided it was
corrupt. Unmounting the partition and trying an fsck reported that it
couldn't find the partition. After a reboot all was well and a fsck
reported no problems.

-- 
    Red herrings strewn hither and yon.

Re: IDE locking (was: Re: RFD: Kernel release numbering)

[CaT]

On Fri, Mar 04, 2005 at 12:44:16PM +1100, CaT wrote:
> The problems were weird. The fs I was copying from decided it was
> corrupt. Unmounting the partition and trying an fsck reported that it
> couldn't find the partition. After a reboot all was well and a fsck
> reported no problems.

Similar stuff with ac12 if dma is on on both drives.

Mar  4 15:15:55 nessie kernel: hdi: dma_timer_expiry: dma status == 0x21
Mar  4 15:16:10 nessie kernel: hdi: DMA timeout error
Mar  4 15:16:10 nessie kernel: hdi: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }
Mar  4 15:16:10 nessie kernel:
Mar  4 15:16:10 nessie kernel: ide: failed opcode was: unknown

Should be noted that hdi does not boot with multisec or dma on.

-- 
    Red herrings strewn hither and yon.

Re: IDE locking (was: Re: RFD: Kernel release numbering)

[Alan Cox]

On Gwe, 2005-03-04 at 01:44, CaT wrote:
> > Depends on your PCI bus and also if the are on the same IRQ. In the same
> Hmm. How can I check on this? What should I look for?

If you've got two promise cards on a VIA 133Mhz or early 266Mhz chipset
for example then there are large numbers of reports both Linux and other
OS about problems.

> The problems were weird. The fs I was copying from decided it was
> corrupt. Unmounting the partition and trying an fsck reported that it
> couldn't find the partition. After a reboot all was well and a fsck
> reported no problems.

That indicates the corruption was in memory not on disk. I take it the
box passes memtest86 fine however ?

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Chris Friesen wrote:
>
> Linus Torvalds wrote:
> 
> > I'll tell you what the problem is: I don't think you'll find anybody to do
> > the parallell "only trivial patches" tree.
> 
> Isn't this what -ac and -as effectively already are?

No. They both end up doing a lot of much fancier stuff. There are patches 
in there that I may not be comfortable with, because they end up doing 
things like totally re-doing the locking for some subsystem. 

Yes, they end up re-doing _broken_ locking, but the point is that they are 
not obvious. They are just "more careful" versions of the -mm tree.

		Linus

Re: RFD: Kernel release numbering

[Chris Wright]

* Linus Torvalds (torvalds@osdl.org) wrote:
> On Thu, 3 Mar 2005, Jeff Garzik wrote:
> In fact, if somebody maintained that kind of tree, especially in BK, it 
> would be trivial for me to just pull from it every once in a while (like 
> ever _day_ if necessary). But for that to work, then that tree would have 
> to be about so _obviously_ not wild patches that it's a no-brainer.
> 
> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.
> 
> Anybody?

Andres Salomon (-as patches) and I have been talking about that at least
regarding security fixes.  It's worth trying in a more complete and
formalized way.  Guess I can be branded a sucker ;-)

> I'll tell you what the problem is: I don't think you'll find anybody to do
> the parallell "only trivial patches" tree. They'll go crazy in a couple of
> weeks. Why? Because it's a _damn_ hard problem. Where do you draw the
> line? What's an acceptable patch? And if you get it wrong, people will
> complain _very_ loudly, since by now you've "promised" them a kernel that
> is better than the mainline. In other words: there's almost zero glory,
> there are no interesting problems, and there will absolutely be people who 
> claim that you're a dick-head and worse, probably on a weekly basis.
> 
> That said, I think in theory it's a great idea. It might even be 
> technically feasible if there was some hard technical criteria for each 
> patch that gets accepted, so that you don't have the burn-out problem. 
> 
> So let's loook at how we could set that up. We need:
> 
>  - a sucker who wants to do this, or a company that pays for somebody good 
>    to do this (and remember: "good" here doesn't necessarily have to mean 
>    technical genius, it's about taking abuse and being stable). The whole 
>    setup should be such that there can never be any question about the 
>    patches for _other_ reasons (to avoid the sucker becoming a target for 
>    abuse), so this person really to some degree would be fairly 
>    mechanical.
> 
>    Don't make it automated, though. That just gets us down the path of 
>    flaming about the scripts and automation. And I'm not claiming that we 
>    should aim for somebody _stupid_, I'm just claiming that it takes a
>    certain kind of person to do something that is not all that glamorous, 
>    and that puts you in the spot.
> 
>    We don't ever want to have that spark of "wouldn't this be cool" in
>    this project. 
> 
>  - some very _technical_ and objective rules on patches. And they should 
>    limit the patches severely, so that people can never blame the sucker 
>    who does the job. For example, I would suggest that "size" be one hard 
>    technical rule. If the patch is more than 100 lines (with context) in
>    size, it's not trivial any more. Really. Two big screenfuls (or four, 
>    for people who still use the ISO-ANSI standard 80x24 vt100)
> 
>    Also, I'd suggest that a _hard_ rule (ie nobody can override it) would 
>    also be that the problem causes an oops, a hang, or a real security
>    problem that somebody can come up with an exploit for (ie no "there
>    could be a two-instruction race" crap. Only "there is a race, and
>    here's how you exploit it"). The exploit wouldn't need to be full code 
>    that gets root, but an explanation of it, at least.
> 
>  - a vetting process. You'd have ten people, and five of them would have 
>    to sign off on the patch, and even a single veto would shoot it down. 
> 
>    Again, this is really to protect the sucker, and make it possible to
>    work: I don't think this can work with a creative person (everybody
>    else calls me "flaky", and I much prefer that "creative" word, it sounds
>    so much better), which I personally believe means that we don't _want_
>    people like Alan, Andrea, Andrew etc etc that have historically maintained
>    their own trees that sometimes have tried to do something like this.
> 
>  - Finally: this tree never has any history past the "last release". When
>    a new kernel comes, the tree is frozen, and never to be touched again.

I like this definition.  The only remaining question is what determines
a 2.6.x.y release?  One patch?  Sure if it's critical enough.  

>    If somebody _else_ wants to base things off this special "sucker tree", 
>    and make a fourth level tree that is based on the _previous_ stable 
>    tree, that's fine, but that's a separate process. He would be totally 
>    free to do so, but the rule is that this particular maintenance program 
>    _never_ gets stuck on an old kernel, like the vendor trees always are. 
> 
>    This is not a long-range tree, it would _purely_ be about one thing and
>    one thing only: the last stable kernel. The people involved (sucker and 
>    vetters all) would never have to remember two different trees, or care 
>    about problems that aren't in the top-of-tree. Keep ti simple, and keep 
>    the rules clear.
> 
> Does this mean that some patches would never go into this tree? Yes. It
> would mean that patches that some people might feel very _strongly_ are
> good patches would never ever show up in this tree, but on the other hand,
> I can see this tree being useful regardless, and I think the lack of
> flexibility in this case is actually the whole _point_ of the tree. The 
> lack of flexibility is the very thing that makes this be the kind of base 
> that anybody else can then hang their own patches on top of. There should 
> never be a situation where "I'd like that tree, but I think xxxx was done 
> wrong".
> 
> Might something like this make people happier? (I wrote "happy" rather
> than "happier" at first, but let's face it, people are better at whining
> than they are at being happy ;)

Heh, maybe people are happiest when they are whining ;-)

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: RFD: Kernel release numbering

[Jens Axboe]

On Thu, Mar 03 2005, Chris Wright wrote:
> >  - Finally: this tree never has any history past the "last release". When
> >    a new kernel comes, the tree is frozen, and never to be touched again.
> 
> I like this definition.  The only remaining question is what determines
> a 2.6.x.y release?  One patch?  Sure if it's critical enough.  

Why should there be one? One of the things I like about this concept is
that it's just a moving tree. There could be daily snapshots like the
-bkX "releases" of Linus's tree, if there are changes from the day
before. It means (hopefully) that no one will "wait for x.y.z.2 because
that is really stable".

-- 
Jens Axboe

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 06:03:36PM +0100, Jens Axboe wrote:
> On Thu, Mar 03 2005, Chris Wright wrote:
> > >  - Finally: this tree never has any history past the "last release". When
> > >    a new kernel comes, the tree is frozen, and never to be touched again.
> > 
> > I like this definition.  The only remaining question is what determines
> > a 2.6.x.y release?  One patch?  Sure if it's critical enough.  
> 
> Why should there be one? One of the things I like about this concept is
> that it's just a moving tree. There could be daily snapshots like the
> -bkX "releases" of Linus's tree, if there are changes from the day
> before. It means (hopefully) that no one will "wait for x.y.z.2 because
> that is really stable".

So that means we do the release often, _and_ provide -bkX snapshots
daily if we happen to take a few days between releases and patches are
pending for some reason.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Jens Axboe wrote:
> 
> Why should there be one? One of the things I like about this concept is
> that it's just a moving tree. There could be daily snapshots like the
> -bkX "releases" of Linus's tree, if there are changes from the day
> before. It means (hopefully) that no one will "wait for x.y.z.2 because
> that is really stable".

Exactly. Th ewhole point of this tree is that there shouldn't be anything 
questionable in it. All the patches are independent, and they are all 
trivial and small.

Which is not to say there couldn't be regressions even from trivial and 
small patches, and yes, there will be an outcry when there is, but we're 
talking minimizing the risk, not making it impossible.

		Linus

Re: RFD: Kernel release numbering

[Chris Wright]

* Linus Torvalds (torvalds@osdl.org) wrote:
> On Thu, 3 Mar 2005, Jens Axboe wrote:
> > 
> > Why should there be one? One of the things I like about this concept is
> > that it's just a moving tree. There could be daily snapshots like the
> > -bkX "releases" of Linus's tree, if there are changes from the day
> > before. It means (hopefully) that no one will "wait for x.y.z.2 because
> > that is really stable".
> 
> Exactly. Th ewhole point of this tree is that there shouldn't be anything 
> questionable in it. All the patches are independent, and they are all 
> trivial and small.
> 
> Which is not to say there couldn't be regressions even from trivial and 
> small patches, and yes, there will be an outcry when there is, but we're 
> talking minimizing the risk, not making it impossible.

OK.  I was aniticpating people's request for an official 2.6.x.y release
(since I've already had that request a bunch).  But as long as the
snapshot can be easily identified in the unlikely case of a regression,
then snapshot could be good enough.
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: RFD: Kernel release numbering

[Sean]

On Thu, March 3, 2005 12:53 pm, Linus Torvalds said:
> On Thu, 3 Mar 2005, Jens Axboe wrote:
>>
>> Why should there be one? One of the things I like about this concept is
>> that it's just a moving tree. There could be daily snapshots like the
>> -bkX "releases" of Linus's tree, if there are changes from the day
>> before. It means (hopefully) that no one will "wait for x.y.z.2 because
>> that is really stable".
>
> Exactly. Th ewhole point of this tree is that there shouldn't be anything
> questionable in it. All the patches are independent, and they are all
> trivial and small.
>
> Which is not to say there couldn't be regressions even from trivial and
> small patches, and yes, there will be an outcry when there is, but we're
> talking minimizing the risk, not making it impossible.
>

Wait a second though, this tree will be branched from the development
mainline.   So it will contain many patches that entered with less
testing.   What will be the policy for dealing with regressions relative
to the previous $sucker release caused by huge patches that entered via
the development tree?   Is reverting them prohibited because of the patch
size?

Sean

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 02:35:29PM -0500, Sean wrote:
> On Thu, March 3, 2005 12:53 pm, Linus Torvalds said:
> > On Thu, 3 Mar 2005, Jens Axboe wrote:
> >>
> >> Why should there be one? One of the things I like about this concept is
> >> that it's just a moving tree. There could be daily snapshots like the
> >> -bkX "releases" of Linus's tree, if there are changes from the day
> >> before. It means (hopefully) that no one will "wait for x.y.z.2 because
> >> that is really stable".
> >
> > Exactly. Th ewhole point of this tree is that there shouldn't be anything
> > questionable in it. All the patches are independent, and they are all
> > trivial and small.
> >
> > Which is not to say there couldn't be regressions even from trivial and
> > small patches, and yes, there will be an outcry when there is, but we're
> > talking minimizing the risk, not making it impossible.
> >
> 
> Wait a second though, this tree will be branched from the development
> mainline.   So it will contain many patches that entered with less
> testing.

Less testing than what?  Remember, we don't have a "test suite" for the
kernel, no matter how much propaganda osdl likes to emit :)

> What will be the policy for dealing with regressions relative
> to the previous $sucker release caused by huge patches that entered via
> the development tree?   Is reverting them prohibited because of the patch
> size?

We'll deal with them as they come, on a case-by-case basis.  Acceptable?

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Sean wrote:
> 
> Wait a second though, this tree will be branched from the development
> mainline.   So it will contain many patches that entered with less
> testing.

Well, since I'd pull basically all the time, all the patches _do_ get 
testing the the -rc kernels. 

But the rules would be that small patches can also be verified 
independently.

And realize that the 2.6.x tree doesn't "change" any way. It doesn't get 
more unruly just because we have a side tree that is being anal about 
things. It's still as stable as it ever is..

		Linus

Re: RFD: Kernel release numbering

[Kyle Moffett]

On Mar 03, 2005, at 14:35, Sean wrote:
> Wait a second though, this tree will be branched from the development
> mainline.   So it will contain many patches that entered with less
> testing.   What will be the policy for dealing with regressions 
> relative
> to the previous $sucker release caused by huge patches that entered via
> the development tree?   Is reverting them prohibited because of the 
> patch
> size?

I can see two conflicting desires in this discussion, the desire to 
continue
development to avoid patch backlog, and the desire to slow down and 
stabilize
to provide a sane release-candidate and release scheme.  Could the two
desires somehow be both resolved simultaneously?

Perhaps instead of forking when 2.6.A is released, Linux could fork 
earlier,
after the 2.6.A-bk series.  After the fork, the main tree would become 
the
new 2.6.A+1-bk, and the forked tree would become 2.6.A+1-pre.  Then the 
final
stabilization and patches could continue while normal kernel development
moves on.  The latest kernel could take advantage of patches to the 
release
kernel, but would be able to maintain the steady patch stream.  The 
release
kernel could be managed by the previously mentioned "sucker", and could 
go
through a more-stabilizing and better tested Release Candidate series, 
and
then maintain post-release bugfixes.  When 2.6.A+1-pre is released, then
all upstream development on the forked 2.6.A-post tree would cease.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: RFD: Kernel release numbering

[Krzysztof Halasa]

Chris Wright <chrisw@osdl.org> writes:

> I like this definition.  The only remaining question is what determines
> a 2.6.x.y release?  One patch?  Sure if it's critical enough.  

Sure. Or a patch for 1-2 days, will less critical things.

And probably no .tar* balls for them. Just a patch against 2.6.x.y-1.
-- 
Krzysztof Halasa

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 08:23 -0800, Linus Torvalds wrote:
> But look at how to solve it. The _logical_ solution is to have a third
> line of defense: we have the -mm trees (wild and wacky patches), and we
> have my tree (hopefully not wacky any more), and it would be good to have
> a third level tree (which I'm just not interested in, because that one
> doesn't do any development any more) which only takes the "so totally not
> wild that it's really boring" patches.
> 
> In fact, if somebody maintained that kind of tree, especially in BK, it 
> would be trivial for me to just pull from it every once in a while (like 
> ever _day_ if necessary). But for that to work, then that tree would have 
> to be about so _obviously_ not wild patches that it's a no-brainer.
> 
> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.

This way you have a fixup tree for the latest 2.6.x release, but does
not resolve the problem of the release quality itself.

It makes more sense to do

2.6.x-pre1 .. preX in your tree until you feel comfortable to move it
into the release tree, where it starts from

2.6.x-rc1 .. rcX bugfix only up to the final release.

>From the release to the next -preX to -rc1 move this tree only handles
the real trivial and urgent fixes and produces 2.6.x.y updates. When the
next -rc1 appears the previous 2.6.x.y is frozen and never touched
again.

This way you have ongoing development in your tree and the -rcX releases
might find more testers than now.

> I'll tell you what the problem is: I don't think you'll find anybody to do
> the parallell "only trivial patches" tree. They'll go crazy in a couple of
> weeks. Why? Because it's a _damn_ hard problem. Where do you draw the
> line? What's an acceptable patch? And if you get it wrong, people will
> complain _very_ loudly, since by now you've "promised" them a kernel that
> is better than the mainline. In other words: there's almost zero glory,
> there are no interesting problems, and there will absolutely be people who 
> claim that you're a dick-head and worse, probably on a weekly basis.

I think when the rules are clear and some gratification would be
available you might find somebody to jump on this train. 

tglx

Re: RFD: Kernel release numbering

[Adrian Bunk]

On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
>...
> But look at how to solve it. The _logical_ solution is to have a third
> line of defense: we have the -mm trees (wild and wacky patches), and we
> have my tree (hopefully not wacky any more), and it would be good to have
> a third level tree (which I'm just not interested in, because that one
> doesn't do any development any more) which only takes the "so totally not
> wild that it's really boring" patches.
> 
> In fact, if somebody maintained that kind of tree, especially in BK, it 
> would be trivial for me to just pull from it every once in a while (like 
> ever _day_ if necessary). But for that to work, then that tree would have 
> to be about so _obviously_ not wild patches that it's a no-brainer.
> 
> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.
>... 
>  - some very _technical_ and objective rules on patches. And they should 
>    limit the patches severely, so that people can never blame the sucker 
>    who does the job. For example, I would suggest that "size" be one hard 
>    technical rule. If the patch is more than 100 lines (with context) in
>    size, it's not trivial any more. Really. Two big screenfuls (or four, 
>    for people who still use the ISO-ANSI standard 80x24 vt100)
>...

This only attacks part of the problem.

Most regressions that annoy users aren't in some core system, they are 
in drivers.

What if $big_driver_update in 2.6.12 fixed a serious bug for some people 
but broke the driver for many other people, and both reverting this 
patch and fixing the driver for the people it's broken for exceeds such 
size limits?

> 			Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 06:08:08PM +0100, Adrian Bunk wrote:
> On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> >...
> > But look at how to solve it. The _logical_ solution is to have a third
> > line of defense: we have the -mm trees (wild and wacky patches), and we
> > have my tree (hopefully not wacky any more), and it would be good to have
> > a third level tree (which I'm just not interested in, because that one
> > doesn't do any development any more) which only takes the "so totally not
> > wild that it's really boring" patches.
> > 
> > In fact, if somebody maintained that kind of tree, especially in BK, it 
> > would be trivial for me to just pull from it every once in a while (like 
> > ever _day_ if necessary). But for that to work, then that tree would have 
> > to be about so _obviously_ not wild patches that it's a no-brainer.
> > 
> > So what's the problem with this approach? It would seem to make everybody
> > happy: it would reduce my load, it would give people the alternate "2.6.x
> > base kernel plus fixes only" parallell track, and it would _not_ have the 
> > testability issue (because I think a lot of people would be happy to test 
> > that tree, and if it was always based on the last 2.6.x release, there 
> > would be no issues.
> >... 
> >  - some very _technical_ and objective rules on patches. And they should 
> >    limit the patches severely, so that people can never blame the sucker 
> >    who does the job. For example, I would suggest that "size" be one hard 
> >    technical rule. If the patch is more than 100 lines (with context) in
> >    size, it's not trivial any more. Really. Two big screenfuls (or four, 
> >    for people who still use the ISO-ANSI standard 80x24 vt100)
> >...
> 
> This only attacks part of the problem.
> 
> Most regressions that annoy users aren't in some core system, they are 
> in drivers.
> 
> What if $big_driver_update in 2.6.12 fixed a serious bug for some people 
> but broke the driver for many other people, and both reverting this 
> patch and fixing the driver for the people it's broken for exceeds such 
> size limits?

Then either the patch author splits out the bug if they want to, or we
punt and say "wait for 2.6.12".  Distros can then decide if they want to
take the whole $big_patch in their releases, if they are near a release
cycle.

I feel that imposing such limits is the only way this can be done and
remain sane.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Greg KH wrote:
> 
> Then either the patch author splits out the bug if they want to, or we
> punt and say "wait for 2.6.12".  Distros can then decide if they want to
> take the whole $big_patch in their releases, if they are near a release
> cycle.

Yes. Exactly.

We're not aiming for "perfect". Just _trying_ to be perfect is what would
kill the whole scheme in the first place. We'd be aiming for "known
rules".

Whether people _agree_ with those rules is then actually not a huge issue. 
There will _always_ be things that people don't agree with. Aiming for 
consistency is worthwhile in itself.

(Of course, the rules _do_ matter in the sense that there has to be some 
point to the consistency. You can have a consistent rule that "the 
ChangeLog entries must rhyme", and I think it's a great rule, and I 
encourage anybody who wants to to set up such a "rhyming kernel tree", but 
that doesn't mean that it makes a lot of difference to people ;).

So havign strict rules that allow _one_ kind of consistency that people 
agree is good is a fine idea.

And Adrian, you can always have a different tree that has another set of 
rules - and if you use BK you can merge the two and have the "combination 
of the rules" tree. The reason I would _stronly_ urge very tight rules is 
that if they aren't tight, it ends up having all the problems we've always 
seen in other trees.

For example, if the "tight rules tree" allowed reverting an otheriwse good
patch because it had a bug (instead of trying to fix the bug), then I
would never be able to pull that tree into mine. It would take development
_backwards_, and thus it might be sensible for a vendor, but it would
automatically mean that it's not a good base for the next kernel version.

And if I can't just say "ok, I'll always take the 'tight rules' tree", 
then we'd get into the forward-and-backward porting hell again, which 
would make the whole tree totally pointless. See my point?

			Linus

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 18:08 +0100, Adrian Bunk wrote:

> This only attacks part of the problem.

It still does not solve the problem of "untested" releases. Users will
still ignore the linus-tree-rcX kernels. 

So we move the real -rcX phase after the so called stable release. 

Doing -rcX from the "sucker" tree up to a stable release makes much more
sense and would have more testers and get back lost confidence.

tglx

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Thomas Gleixner wrote:
> 
> It still does not solve the problem of "untested" releases. Users will
> still ignore the linus-tree-rcX kernels. 

.. and maybe that problem is unsolvable. People certainly argued 
vehemently that anything we do to try to make test releases (renaming etc) 
won't help.

So what do you do if you find an unsolvable problem? You don't solve it: 
you make sure it's not a show-stopper.

So part of the idea of having the "other tree" is that it ends up solving 
the "hmm, we missed that detail" problem. And by _not_ giving it release 
numbers or any schedule at all, people can't _wait_ for it. 

Sneaky. That's my middle name.

		Linus

Re: RFD: Kernel release numbering

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Thu, 3 Mar 2005, Thomas Gleixner wrote:
> 
>>It still does not solve the problem of "untested" releases. Users will
>>still ignore the linus-tree-rcX kernels. 
> 
> 
> .. and maybe that problem is unsolvable. People certainly argued 
> vehemently that anything we do to try to make test releases (renaming etc) 
> won't help.
> 
> So what do you do if you find an unsolvable problem? You don't solve it: 
> you make sure it's not a show-stopper.

I disagree it's unsolvable:

1) At some point in the -rc cycle, you put your foot down and say 
"nothing but bugfixes."

2) Indicate this foot-stomp in a manner that a script can easily notice.

That's all the 2.4.x's -pre/-rc accomplishes.  It encourages people to 
test, by telling them when their testing would be most useful.

	Jeff

Re: RFD: Kernel release numbering

[David S. Miller]

On Thu, 03 Mar 2005 14:52:21 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> I disagree it's unsolvable:
> 
> 1) At some point in the -rc cycle, you put your foot down and say 
> "nothing but bugfixes."

Linus actually did, as Andrew showed you, and it was actually followed
quite well.

You keep ignoring this evidence, why?

You can quiet me up about this by showing counter evidence to what
Andrew pointed out to you.

Re: RFD: Kernel release numbering

[Jeff Garzik]

David S. Miller wrote:
> On Thu, 03 Mar 2005 14:52:21 -0500
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> 
>>I disagree it's unsolvable:
>>
>>1) At some point in the -rc cycle, you put your foot down and say 
>>"nothing but bugfixes."
> 
> 
> Linus actually did, as Andrew showed you, and it was actually followed
> quite well.
> 
> You keep ignoring this evidence, why?
> 
> You can quiet me up about this by showing counter evidence to what
> Andrew pointed out to you.

I agree this occurred.  I'm not ignoring the evidence, you are ignoring 
the part you didn't quote -- the key component of the "users don't test" 
problem.

A user who doesn't follow LKML does not know that Linus put his foot 
down in 2.6.11-rc3.  or 2.6.10-rc2.  or 2.6.9-rc1.  A user just sees "at 
some random point, which is never consistent, it becomes bugfixes only."

The lack of consistency is the problem.  That is why posters in this 
thread keep suggesting a -pre/-rc split.  That is why posters in this 
thread talk about "users don't trust -rc to mean -rc."

Marcelo consistently says "-rc means serious bugfixes only" and never 
deviates from that.  And that builds users TRUST.


"putting down your foot" is only half the solution.

The other half is, "users need not follow LKML to know when this occurs."

	Jeff

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 14:52 -0500, Jeff Garzik wrote:
> I disagree it's unsolvable:
> 
> 1) At some point in the -rc cycle, you put your foot down and say 
> "nothing but bugfixes."

Release candidates are supposed to be bugfix only from -rc1. Everything
else can only be called the "ridiculous count".

> That's all the 2.4.x's -pre/-rc accomplishes.  It encourages people to 
> test, by telling them when their testing would be most useful.

Correct, but again 2.4 is a different beast as no active development is
taking place.

In a active development you should move the -rc step out of the
development line into a seperate release line after the -preX steps. 

It has two advantages:

1. The release process is encapsulated and secure against non bugfix
merges. This can be "sold" to users for testing.

2. The development cycle is more continous. While -rc1 is led to release
2.6.X the preparations for 2.6.X+1-pre1 are moving on. This might
shorten the overall release cycles as well.

tglx

Re: RFD: Kernel release numbering

[Jeff Garzik]

As a further elaboration...

The problem with the current 2.6-rc setup is a _human_ _communications_ 
problem.

Users have been trained in a metaphor that is applied uniformly across 
all software projects that use the metaphor:

	test release:		a useful merge/testing point
	release candidate:	bugfixes only, test test test

Linux does it differently.

It's hard enough to get users to test...   now we have raised the 
barrier even higher by abusing a common metaphor.  A metaphor that is 
used _succesfully_ elsewhere to get users to test.

"release candidate" is a promise to users that the current tree is close 
to what the release will look like, and only major fixes will appear 
between -rc and -final.

We broke that promise.  In human interface terms, this is like 
redefining the "garbage can" icon to mean "save your work."  ;-)

	Jeff

Re: RFD: Kernel release numbering

[Gene Heskett]

On Thursday 03 March 2005 16:07, Jeff Garzik wrote:
>As a further elaboration...
>
>The problem with the current 2.6-rc setup is a _human_
> _communications_ problem.
>
>Users have been trained in a metaphor that is applied uniformly
> across all software projects that use the metaphor:
>
> test release:  a useful merge/testing point
> release candidate: bugfixes only, test test test
>
>Linux does it differently.
>
>It's hard enough to get users to test...   now we have raised the
>barrier even higher by abusing a common metaphor.  A metaphor that
> is used _succesfully_ elsewhere to get users to test.
>
>"release candidate" is a promise to users that the current tree is
> close to what the release will look like, and only major fixes will
> appear between -rc and -final.
>
>We broke that promise.  In human interface terms, this is like
>redefining the "garbage can" icon to mean "save your work."  ;-)
>
> Jeff

I've seen this comment before too, and I still think it says it best:

The full release s/b the last rc with NO changes other than its name.

Now we are faced with a final that may have another 50k+ of patches 
applied over what made the rc5.  IMO, in the immediately past case, 
that should not have been final, but an rc6.

I personally vote for going back to the -pre series where we get to 
test new ideas & maybe morph the neighbors dog/cat.  At some point it 
gets stable enough to call it -rc1, at which point nothing but 
bugfixes should be allowed in until the final.  That way we have a 
develop, then stabilize, then develop the next, then stabilize it set 
of stairsteps.

I personally build and run as many of them as I can find the time to 
do.  I just applied the bk-1394-patch and its building because 2.6.11 
isn't really comfortable running my movie camera yet.

I also haven't built any more of Andrews -mm's since the last time I 
got told off about it.  I can go back to doing that too, if the 
results of my testing it aren't going to be thrown out like the babys 
bath water.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: RFD: Kernel release numbering

[Krzysztof Halasa]

Gene Heskett <gene.heskett@verizon.net> writes:

> I've seen this comment before too, and I still think it says it best:
>
> The full release s/b the last rc with NO changes other than its name.
>
> Now we are faced with a final that may have another 50k+ of patches 
> applied over what made the rc5.  IMO, in the immediately past case, 
> that should not have been final, but an rc6.

Not sure about it. I think last-rc -> final diff should be allowed
to contain trivial patches, like those qualified for 2.6.x.y.
-- 
Krzysztof Halasa

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 11:37 -0800, Linus Torvalds wrote:
> > It still does not solve the problem of "untested" releases. Users will
> > still ignore the linus-tree-rcX kernels. 
> 
> .. and maybe that problem is unsolvable. People certainly argued 
> vehemently that anything we do to try to make test releases (renaming etc) 
> won't help.

It wont help, if you keep it in the development line. If you move it out
of the development line into the "other tree" then it is likely to be
accepted as _real_ release candidates which get a proper testing
coverage before declaring it stable release nr. XYZ.

Users _are_ scared off by the current release quality. Your model is
ignoring this part of the problem and just provides a pacifier gimmick.

> So part of the idea of having the "other tree" is that it ends up solving 
> the "hmm, we missed that detail" problem. And by _not_ giving it release 
> numbers or any schedule at all, people can't _wait_ for it. 

After the _stable_ release, of course no schedule and release numbers
are necessary. The proposed scheme will work nicely.

> Sneaky. That's my middle name.
> 
> 		Linus

People are clever enough to debunk sneaky gimmicks.

tglx

Re: RFD: Kernel release numbering

[Rene Herman]

Linus Torvalds wrote:

> On Thu, 3 Mar 2005, Thomas Gleixner wrote:
> 
>>It still does not solve the problem of "untested" releases. Users will
>>still ignore the linus-tree-rcX kernels. 
> 
> 
> .. and maybe that problem is unsolvable. People certainly argued 
> vehemently that anything we do to try to make test releases (renaming etc) 
> won't help.

No, we argued that _if_ you don't do real -rc's no amount of renaming 
will trick people into believing they are (for long). Note how that's 
what has happened now. Your -rc's are -pre's, certainly the first ones 
for each kernel, and that's exactly how people treat them -- that is, 
many avoid them.

Doing -rc1 to release and beyond from that per-release "sucker tree" as 
you call it (I prefer "release tree") makes more sense. This gets you 
real release management and the only thing left to do is appoint the 
release manager.

> So what do you do if you find an unsolvable problem? You don't solve it: 
> you make sure it's not a show-stopper.

It's not unsolveable. Doing real -pre's and -rc's (which means "doing 
doing real -rc's" in addition to the current situation) would at least 
to a degree solve it.

> Sneaky. That's my middle name.

Judging by the fact that apparently you know have to few testers "seeing 
right through Linus" would seem to be everybody else's, though.

Rene.

Re: RFD: Kernel release numbering

[Jeff Garzik]

Thomas Gleixner wrote:
> On Thu, 2005-03-03 at 18:08 +0100, Adrian Bunk wrote:
> 
> 
>>This only attacks part of the problem.
> 
> 
> It still does not solve the problem of "untested" releases. Users will
> still ignore the linus-tree-rcX kernels. 
> 
> So we move the real -rcX phase after the so called stable release. 
> 
> Doing -rcX from the "sucker" tree up to a stable release makes much more
> sense and would have more testers and get back lost confidence.


Nod.  I really don't think the key penguins understand that there is 
even a problem here.  Let me attempt to re-state the problem:


	There is no flag day when "bugfixes only" mode begins.


There are two component to this problem:

1) Release maintainers need to avoid merging non-bugfixes.  Lately, the 
key penguins _have_ been doing their job here.  This manifested in 
2.6.11-rc4, 2.6.11-rc5.

2) This "flag day" when bugfixes-only mode starts needs to be completely 
obvious to _scripts_ and really dumb people.  Posting to LKML "with this 
-rc, I am only taking serious bugfixes" doesn't cut it.  There must be a 
clear, consistent point where testing may begin.


As a result of this problem, people have learned [just re-read this 
thread if you don't believe me] that "-rc" doesn't really mean Release 
Candidate until -rc2 or -rc3 or so.  And as a result of that, people do 
less testing.

	Jeff

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 14:42 -0500, Jeff Garzik wrote:
> 1) Release maintainers need to avoid merging non-bugfixes.  Lately, the 
> key penguins _have_ been doing their job here.  This manifested in 
> 2.6.11-rc4, 2.6.11-rc5.

True, but the confidence of users in -rc is gone already. So testing
happens when the "stable" release is out, but thats too late.

> 2) This "flag day" when bugfixes-only mode starts needs to be completely 
> obvious to _scripts_ and really dumb people.  Posting to LKML "with this 
> -rc, I am only taking serious bugfixes" doesn't cut it.  There must be a 
> clear, consistent point where testing may begin.

If you clearly seperate out the -rc process of the development tree then
it is no question how dump scripts and people are. The -rc tree is
untouchable for anything else than bugfixes.

tglx

Re: RFD: Kernel release numbering

[Daniel Barkalow]

On Thu, 3 Mar 2005, Linus Torvalds wrote:

>  - some very _technical_ and objective rules on patches. And they should 
>    limit the patches severely, so that people can never blame the sucker 
>    who does the job. For example, I would suggest that "size" be one hard 
>    technical rule. If the patch is more than 100 lines (with context) in
>    size, it's not trivial any more. Really. Two big screenfuls (or four, 
>    for people who still use the ISO-ANSI standard 80x24 vt100)

One thing that's worth pointing out is that sometimes the 20-line patch is
sufficient to solve the problem, but is lousy code. That's fine for a tree
that will be frozen in a couple of months after only getting little fixes
to other files, but mainline should get a real fix, which wouldn't be
acceptable in the sucker tree. So 2.6.(x+1) shouldn't automatically get
2.6.x.y. Should reverting a 200-line patch which turned out to need
another 200 lines to work be acceptable?

>    Also, I'd suggest that a _hard_ rule (ie nobody can override it) would 
>    also be that the problem causes an oops, a hang, or a real security
>    problem that somebody can come up with an exploit for (ie no "there
>    could be a two-instruction race" crap. Only "there is a race, and
>    here's how you exploit it"). The exploit wouldn't need to be full code 
>    that gets root, but an explanation of it, at least.

Similar rule for driver patches: you can patch a driver if it makes the 
device not work (but you couldn't patch the core)?

> Does this mean that some patches would never go into this tree? Yes. It
> would mean that patches that some people might feel very _strongly_ are
> good patches would never ever show up in this tree, but on the other hand,
> I can see this tree being useful regardless, and I think the lack of
> flexibility in this case is actually the whole _point_ of the tree. The 
> lack of flexibility is the very thing that makes this be the kind of base 
> that anybody else can then hang their own patches on top of. There should 
> never be a situation where "I'd like that tree, but I think xxxx was done 
> wrong".

The good patches will show up in 2.6.(x+1).1, which should be
sufficient. It's not the same sucker tree, but it's a sucker tree.

	-Daniel
*This .sig left intentionally blank*

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 12:52:52PM -0500, Daniel Barkalow wrote:
> On Thu, 3 Mar 2005, Linus Torvalds wrote:
> 
> >  - some very _technical_ and objective rules on patches. And they should 
> >    limit the patches severely, so that people can never blame the sucker 
> >    who does the job. For example, I would suggest that "size" be one hard 
> >    technical rule. If the patch is more than 100 lines (with context) in
> >    size, it's not trivial any more. Really. Two big screenfuls (or four, 
> >    for people who still use the ISO-ANSI standard 80x24 vt100)
> 
> One thing that's worth pointing out is that sometimes the 20-line patch is
> sufficient to solve the problem, but is lousy code. That's fine for a tree
> that will be frozen in a couple of months after only getting little fixes
> to other files, but mainline should get a real fix, which wouldn't be
> acceptable in the sucker tree. So 2.6.(x+1) shouldn't automatically get
> 2.6.x.y. Should reverting a 200-line patch which turned out to need
> another 200 lines to work be acceptable?

It's simple in bk to revert a patch.  So in this instance, when the
2.6.x person pulls in the 2.6.x.y tree, they just revert the offending
patch, and move on.  Actually, the maintainer applying the offending
patch would do it, in their tree, before they sent it to Linus.  Or they
do it by the normal patch way, if they don't use bk.

So, not a problem.

> >    Also, I'd suggest that a _hard_ rule (ie nobody can override it) would 
> >    also be that the problem causes an oops, a hang, or a real security
> >    problem that somebody can come up with an exploit for (ie no "there
> >    could be a two-instruction race" crap. Only "there is a race, and
> >    here's how you exploit it"). The exploit wouldn't need to be full code 
> >    that gets root, but an explanation of it, at least.
> 
> Similar rule for driver patches: you can patch a driver if it makes the 
> device not work (but you couldn't patch the core)?

If it's a bugfix for the core, that met the above rules, I wouldn't mind
it at all.  See the sysfs core patch that made it in between 2.6.11-rc5
and 2.6.11 for such an example.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Jeff Garzik]

Linus Torvalds wrote:
> In fact, if somebody maintained that kind of tree, especially in BK, it 
> would be trivial for me to just pull from it every once in a while (like 
> ever _day_ if necessary). But for that to work, then that tree would have 
> to be about so _obviously_ not wild patches that it's a no-brainer.
> 
> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.

The only problem I see with this -- and its a minor problem -- is that 
some patches that belong in the 2.6.X.Y tree go straight to you/Andrew, 
rather than to $sucker.

It's perfectly workable from a BK standpoint to do

	-> linux-2.6 commit
	-> cpcset into linux-2.6.X.Y [see Documentation/BK-usage/cpcset]
	-> pull from linux-2.6.X.Y into linux-2.6 [dups cset, but no
	   real code change]

but that causes dups in the BK changelog and history.  Not a big deal, 
though, just a minor technical nit.

	Jeff

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 01:04:49PM -0500, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >In fact, if somebody maintained that kind of tree, especially in BK, it 
> >would be trivial for me to just pull from it every once in a while (like 
> >ever _day_ if necessary). But for that to work, then that tree would have 
> >to be about so _obviously_ not wild patches that it's a no-brainer.
> >
> >So what's the problem with this approach? It would seem to make everybody
> >happy: it would reduce my load, it would give people the alternate "2.6.x
> >base kernel plus fixes only" parallell track, and it would _not_ have the 
> >testability issue (because I think a lot of people would be happy to test 
> >that tree, and if it was always based on the last 2.6.x release, there 
> >would be no issues.
> 
> The only problem I see with this -- and its a minor problem -- is that 
> some patches that belong in the 2.6.X.Y tree go straight to you/Andrew, 
> rather than to $sucker.
> 
> It's perfectly workable from a BK standpoint to do
> 
> 	-> linux-2.6 commit
> 	-> cpcset into linux-2.6.X.Y [see Documentation/BK-usage/cpcset]
> 	-> pull from linux-2.6.X.Y into linux-2.6 [dups cset, but no
> 	   real code change]

That's fine with me to do.  As long as someone points out to $sucker
that such a patch should go into 2.6.x.y.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Andrew Morton]

Greg KH <greg@kroah.com> wrote:
>
> > It's perfectly workable from a BK standpoint to do
> > 
> > 	-> linux-2.6 commit
> > 	-> cpcset into linux-2.6.X.Y [see Documentation/BK-usage/cpcset]
> > 	-> pull from linux-2.6.X.Y into linux-2.6 [dups cset, but no
> > 	   real code change]
> 
> That's fine with me to do.  As long as someone points out to $sucker
> that such a patch should go into 2.6.x.y.

That's the only way it _can_ work.  The maintainer of 2.6.x.y shouldn't be
put in a position of having to locate the patches which he needs.

Like it or not, Vojtech is still the maintainer of the input system in
2.6.x.y and he should be the primary guy who keeps an eye out for patches
which needs to be applied there.

If we go overboard here, every maintainer will end up maintaining
another tree of "stuff which needs to be backported to 2.6.x.y", which is
probably more work than we want to do.

As long as we can keep it down to "small and really critical things" then
it should work OK.

Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
development skills - it's just patchmonkeying the things which maintainers
send him.

Re: RFD: Kernel release numbering

[Andrea Arcangeli]

On Thu, Mar 03, 2005 at 03:17:52PM -0800, Andrew Morton wrote:
> That's the only way it _can_ work.  The maintainer of 2.6.x.y shouldn't be

Andrew, what about my suggestion of shifting left x.y of 8 bits? ;) Do
we risk the magic 2.7 number to get us stuck in unstable mode for 2
years instead of 2 months? Doesn't 2.6.x.y pose the same risk but
by also breaking the numbering and the stable kernel identification for
no good reason? (ignoring the "2.6." part that carries no useful info
anymore ;)

Re: RFD: Kernel release numbering

[Andrew Morton]

Andrea Arcangeli <andrea@suse.de> wrote:
>
> On Thu, Mar 03, 2005 at 03:17:52PM -0800, Andrew Morton wrote:
> > That's the only way it _can_ work.  The maintainer of 2.6.x.y shouldn't be
> 
> Andrew, what about my suggestion of shifting left x.y of 8 bits? ;) Do
> we risk the magic 2.7 number to get us stuck in unstable mode for 2
> years instead of 2 months? Doesn't 2.6.x.y pose the same risk but
> by also breaking the numbering and the stable kernel identification for
> no good reason? (ignoring the "2.6." part that carries no useful info
> anymore ;)

I think this is all a bit of a storm in a teacup, really.

2.6.x is making good progress but there have been a handful of prominent
regressions which seem to be making people think that the whole process is
bust.  I don't believe that this has been proven yet.

There is still potential to make good improvements to the existing
processes, and the main way of doing this is for the various subsystems to
be a bit more disciplined.  That means:

a) Have all your 2.6.n stuff ready to go when 2.6.n-1 is released.

b) Merge your 2.6.n stuff promptly - within two weeks of the 2.6.n-1 release.

c) Then, keep your sticky paws off it.  New development and
   not-completely-trustworthy development goes into your subsystem tree and
   Linus's tree just gets bugfixes.

That's how it _should_ work, and I'm not sure that we're sufficiently close
to it now.

Or, to put it another way, we're getting a small number of irritating
regressions, mainly in device drivers which is giving the whole thing a bad
rep.  Is there some way in which we can fix that problem without
reinventing the whole world?

Re: RFD: Kernel release numbering

[Jochen Striepe]

    Hi,

On 03 Mar 2005, Andrew Morton wrote:
> 2.6.x is making good progress but there have been a handful of prominent
> regressions which seem to be making people think that the whole process is
> bust.  I don't believe that this has been proven yet.

Sorry -- what you (with the vision of a kernel developer) are seeing
here surely is interesting, but it's not the point:

The point is what the *users* think. Just in case it still hasn't been
made clear enough in this thread: If your user base gets the impression
the development process isn't reliable any longer, you won't get your
kernel tested as much as you want.

Please remember why this thread started. It was a proposal to get more
users testing the rc kernels. 


So I hope the latest proposal really helps making releases contain fewer
surprises.


Greetings,

Jochen.
-- 
All I want is a warm bed and a kind word and unlimited power.
         -- Ashleigh Brilliant

Re: RFD: Kernel release numbering

[Andrew Morton]

Jochen Striepe <jochen@tolot.escape.de> wrote:
>
>     Hi,
> 
> On 03 Mar 2005, Andrew Morton wrote:
> > 2.6.x is making good progress but there have been a handful of prominent
> > regressions which seem to be making people think that the whole process is
> > bust.  I don't believe that this has been proven yet.
> 
> Sorry -- what you (with the vision of a kernel developer) are seeing
> here surely is interesting, but it's not the point:
> 
> The point is what the *users* think. Just in case it still hasn't been
> made clear enough in this thread: If your user base gets the impression
> the development process isn't reliable any longer, you won't get your
> kernel tested as much as you want.

You cannot have it both ways.  Either the kernel needs testers, or it is
"stable".  See how these are opposites?

We don't _need_ people to test stable kernels, because they're stable. 
(OK, we'll pick up on a few things, but we'd pick up on them if people were
testing tip-of-tree, as well).

The 2.6.x.y thing is a service to people who want 2.6.x with kinks ironed
out.  It's not particularly interesting or useful from a development POV,
apart from its potential to attract a few people who are presently stuck on
2.4 or 2.6.crufty.

> 
> So I hope the latest proposal really helps making releases contain fewer
> surprises.
> 

It won't help that at all.  None of these proposals will increase testing
of tip-of-tree.  In fact the 2.6.x proposal may decrease that level of
that testing, although probably not much.

There is no complete answer to all of this, because there are competing
needs.  It's a question of balance.

RE: RFD: Kernel release numbering

[Hua Zhong]

> You cannot have it both ways.  Either the kernel needs 
> testers, or it is "stable".  See how these are opposites?

I think one of the fundamental problems is "either the kernel needs more
features, or it needs stablization". You cannot have it both ways. With the
current model, the kernel develops at a faster pace than testers can keep up
with, and that's why you feel there aren't enough testers.

Not everyone downloads a kernel every day or even every week. Just once a
while. If you roll out a kernel, you need to give some time to people to
test it out. However, with the current model the kernel keeps adding
features, non-bug fixes, etc, _and completely abandons the previous one and
moves on_. So what's the point of testing? When I download 2.6.9, 2.6.11
might have come out. Even if bug reports do not become obosolete, they are
outpaced by new bugs.

Agreed we need a balance. The problem is the 2.6 focuses too much on
development than stablization. The old "stable release maintainer" model was
completely abandoned. Surely that was not an exciting job, but people need
it.

Hua

Re: RFD: Kernel release numbering

[Jeff Garzik]

Andrew Morton wrote:
> It won't help that at all.  None of these proposals will increase testing
> of tip-of-tree.  In fact the 2.6.x proposal may decrease that level of
> that testing, although probably not much.

Giving humans a well-known point where bugfixes-only mode starts would 
help.  Such as the -pre/-rc split does in 2.4.x.

	Jeff

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> Andrew Morton wrote:
>  > It won't help that at all.  None of these proposals will increase testing
>  > of tip-of-tree.  In fact the 2.6.x proposal may decrease that level of
>  > that testing, although probably not much.
> 
>  Giving humans a well-known point where bugfixes-only mode starts would 
>  help.  Such as the -pre/-rc split does in 2.4.x.

Yup, sure.  I agree that we should be using Marcelo methodology on 2.6.x
release numbering.  Last time I mentioned it to Linus I didn't understand
the reply ;)

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 21:30 -0800, Andrew Morton wrote:
> You cannot have it both ways.  Either the kernel needs testers, or it is
> "stable".  See how these are opposites?

I don't see a contradiction. You need testers for release candidates to
make them stable. The problem is that Linux release candidates are not
release candidates. 

> We don't _need_ people to test stable kernels, because they're stable. 
> (OK, we'll pick up on a few things, but we'd pick up on them if people were
> testing tip-of-tree, as well).

I don't see that the releases are stable. They are defined stable by
proclamation. 

> The 2.6.x.y thing is a service to people who want 2.6.x with kinks ironed
> out.  It's not particularly interesting or useful from a development POV,
> apart from its potential to attract a few people who are presently stuck on
> 2.4 or 2.6.crufty.

This 2.6.x.y tree will change nothing as long as the underlying problem
is not solved.
 
> It won't help that at all.  None of these proposals will increase testing
> of tip-of-tree.  In fact the 2.6.x proposal may decrease that level of
> that testing, although probably not much.
> There is no complete answer to all of this, because there are competing
> needs.  It's a question of balance.

A clearly defined switch from -preX to -rc will give the avarage user a
clear sign where he might jump in and test. 

2.6.11-rc5 (which is -pre5 in disguise) would have been the real point
for a -rc1 ...-rcX freeze and testing phase.

tglx

Re: RFD: Kernel release numbering

[Andrew Morton]

Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Thu, 2005-03-03 at 21:30 -0800, Andrew Morton wrote:
> > You cannot have it both ways.  Either the kernel needs testers, or it is
> > "stable".  See how these are opposites?
> 
> I don't see a contradiction.

There is a *direct* contradition, but it's not important.

> I don't see that the releases are stable. They are defined stable by
> proclamation. 

If they were stable we'd release the darn things!  *obviously* -rc kernels
are expected to still have problems.

-rc just means "please start testing", not "deploy me on your corporate
database server".

People are smart enough to know that -rc3 will be less buggy than -rc1.

And if they're worried about bugs then why are they running -rc's at all?

> This 2.6.x.y tree will change nothing as long as the underlying problem
> is not solved.

What underlying problem?  The fact that -rc1 comes a bit too early?  Spare
me, that's just a nothing.  Anyone who is testing -rc kernels knows the
score.

That being said, yes, I agree that we should use 2.4-style -pre and -rc. 
But changing the names of things won't change anything.

> > It won't help that at all.  None of these proposals will increase testing
> > of tip-of-tree.  In fact the 2.6.x proposal may decrease that level of
> > that testing, although probably not much.
> > There is no complete answer to all of this, because there are competing
> > needs.  It's a question of balance.
> 
> A clearly defined switch from -preX to -rc will give the avarage user a
> clear sign where he might jump in and test. 

The average user has learnt "rc1 == pre1".  I don't expect that it matters
much at all.

Re: RFD: Kernel release numbering

[Jens Axboe]

On Fri, Mar 04 2005, Andrew Morton wrote:
> The average user has learnt "rc1 == pre1".  I don't expect that it
> matters much at all.

The average user and lkml reader, perhaps. But I don't understand
why Linus refuses to use proper -preX/-rcX naming, it would
clear up a lot of confusion imho. It's just the logical thing
to do, Marcelo gets it completely right. That -rcX and -rcX+1
differ in what they mean is really confusing and opposite of
basically anything else out there.

With the 2.6.x-release tree and proper -pre/-rc naming, I would
be perfectly happy :-)

-- 
Jens Axboe

Re: RFD: Kernel release numbering

[Andrew Morton]

Jens Axboe <axboe@suse.de> wrote:
>
> On Fri, Mar 04 2005, Andrew Morton wrote:
>  > The average user has learnt "rc1 == pre1".  I don't expect that it
>  > matters much at all.
> 
>  The average user and lkml reader, perhaps. But I don't understand
>  why Linus refuses to use proper -preX/-rcX naming

Me either.  And because people just will insist on arbitrarily dinking with
Cc: lines, he's not listening to us any more.

There.  Fixed.

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Andrew Morton wrote:
>
> Jens Axboe <axboe@suse.de> wrote:
> >
> > On Fri, Mar 04 2005, Andrew Morton wrote:
> >  > The average user has learnt "rc1 == pre1".  I don't expect that it
> >  > matters much at all.
> > 
> >  The average user and lkml reader, perhaps. But I don't understand
> >  why Linus refuses to use proper -preX/-rcX naming
> 
> Me either.  And because people just will insist on arbitrarily dinking with
> Cc: lines, he's not listening to us any more.

I've long since decided that there's no point to making "-pre". What's the 
difference between a "-pre" and a daily -bk snapshot? Really?

So when I do a release, it _is_ an -rc. The fact that people have trouble 
understanding this is not _my_ fault.

		Linus

Re: RFD: Kernel release numbering

[Jeff Garzik]

Linus Torvalds wrote:
> I've long since decided that there's no point to making "-pre". What's the 
> difference between a "-pre" and a daily -bk snapshot? Really?

Several non-BK developers use the first -rc1 as a merge point.

Others simply trust that _Linus_ has a lot more smarts than an automated 
script, about deciding when a good testing point should occur.  Holy 
Penguin Pee has value, they feel.


> So when I do a release, it _is_ an -rc. The fact that people have trouble 
> understanding this is not _my_ fault.

If you want people to start testing, a good first step would be 
understanding why this is so.

Users have been trained that -rc means "serious bugfixes only".  You are 
trying to re-train them.  That just won't work.

When you do an -rc1 or -rc2, it is not serious bugfixes only. 
_Especially_ rc1.  rc1 is in no way "bugfixes only."  Non-BK developers 
just treat the first couple -rc's as a merge point, while the rest of us 
BK developers have already gone into "send bugfixes only" mode.

You are fighting an uphill battle against user perceptions and training.

	Jeff

Re: RFD: Kernel release numbering

[Steven Cole]

Jeff Garzik wrote:
> Linus Torvalds wrote:
> 
>> I've long since decided that there's no point to making "-pre". What's 
>> the difference between a "-pre" and a daily -bk snapshot? Really?
> 
> 
> Several non-BK developers use the first -rc1 as a merge point.
> 
> Others simply trust that _Linus_ has a lot more smarts than an automated 
> script, about deciding when a good testing point should occur.  Holy 
> Penguin Pee has value, they feel.
> 
> 
>> So when I do a release, it _is_ an -rc. The fact that people have 
>> trouble understanding this is not _my_ fault.
> 
> 
> If you want people to start testing, a good first step would be 
> understanding why this is so.
> 
> Users have been trained that -rc means "serious bugfixes only".  You are 
> trying to re-train them.  That just won't work.
> 
> When you do an -rc1 or -rc2, it is not serious bugfixes only. 
> _Especially_ rc1.  rc1 is in no way "bugfixes only."  Non-BK developers 
> just treat the first couple -rc's as a merge point, while the rest of us 
> BK developers have already gone into "send bugfixes only" mode.
> 
> You are fighting an uphill battle against user perceptions and training.
> 
>     Jeff
> 

Here's an idea which might just be too simple, but here it is anyway:

Modifiy the bk snapshot scripts to name the 2.6.x series snapshots as -PREy
instead of -BKy.  That way, the general population of users will see
the -bk snapshots as -pre releases.  According to Linus, pre == bk.  So,
name them as such.

Linus, wait for at least two weeks before releasing the first -rc.
That way, the bulk on the thundering herd of patches will be hopefully
be merged by then.  And users will have 2.6.x-PRE[1..14] to test.
The hard part for the kernel.org script writer might be to disable
the -bk/-pre snapshot once the first -rc is out.

Since your _intent_ is that an -rc really be an -rc, make it so.  It
shouldn't take more than a release or two to train the maintainers
that the post-2.6.11 -rc's are _really_ release candidates.

Steven

Re: RFD: Kernel release numbering

[Barry K. Nathan]

On Fri, Mar 04, 2005 at 12:07:23PM -0700, Steven Cole wrote:
> 
> Here's an idea which might just be too simple, but here it is anyway:
> 
> Modifiy the bk snapshot scripts to name the 2.6.x series snapshots as -PREy
> instead of -BKy.  That way, the general population of users will see
> the -bk snapshots as -pre releases.  According to Linus, pre == bk.  So,
> name them as such.

I heartily second this!! If "pre" == "bk", then make it "pre"!

> Linus, wait for at least two weeks before releasing the first -rc.
> That way, the bulk on the thundering herd of patches will be hopefully
> be merged by then.  And users will have 2.6.x-PRE[1..14] to test.
> The hard part for the kernel.org script writer might be to disable
> the -bk/-pre snapshot once the first -rc is out.

Errh... personally, I find the -rc-bk snapshots to be useful sync
points. They're also what seems to make it into davej's
"rawhide"/"fc-devel" Fedora testing kernels. (Perhaps those don't get
widely tested, but they do get *some* testing -- e.g. they're how I
managed to hit (and get fixed) the TCP stack overflow.)

I guess the best thing would be for the script to revert to the current
("-bk") naming scheme once -rc1 is out. Otherwise it would need to do,
say, 2.6.12-rc2-pre1 instead of 2.6.12-rc1-bk1, and while that seems
natural to me, I don't know how the rest of the planet's human population
would react...

-Barry K. Nathan <barryn@pobox.com>

Re: RFD: Kernel release numbering

[William Park]

On Fri, Mar 04, 2005 at 09:57:38AM -0800, Linus Torvalds wrote:
> I've long since decided that there's no point to making "-pre". What's
> the difference between a "-pre" and a daily -bk snapshot? Really?
> 
> So when I do a release, it _is_ an -rc. The fact that people have
> trouble understanding this is not _my_ fault.

My feeling is that there is too many numbers in the kernel version.  
I think 3 numbers are good enough to get people to try out (knowingly or
not).  So,
    2.6.{11,12,13,...} -- for testing (a.k.a. -rc, -pre)
    2.7 -- stable release
    2.7.{1,2,3,...} -- for testing
    2.8 -- another stable release
    ...
    2.125 -- when last IDE bug is fixed.
    3.0 -- stable release
    3.0.{1,2,3,...} -- for testing
    ...

Re: RFD: Kernel release numbering

[Jeff Garzik]

Or to put it more simply:


The people we want testing these kernels have been trained to expect 
certain things from a Release Candidate.

These people don't have time to read LKML and understand Linus's 
deviation from the norm.

Therefore, if you want them to test, follow their expectations.

As I said...  it's a human not technical issue.

	Jeff

Re: RFD: Kernel release numbering

[Nicolas Pitre]

On Fri, 4 Mar 2005, Linus Torvalds wrote:

> 
> 
> On Fri, 4 Mar 2005, Andrew Morton wrote:
> >
> > Jens Axboe <axboe@suse.de> wrote:
> > >
> > > On Fri, Mar 04 2005, Andrew Morton wrote:
> > >  > The average user has learnt "rc1 == pre1".  I don't expect that it
> > >  > matters much at all.
> > > 
> > >  The average user and lkml reader, perhaps. But I don't understand
> > >  why Linus refuses to use proper -preX/-rcX naming
> > 
> > Me either.  And because people just will insist on arbitrarily dinking with
> > Cc: lines, he's not listening to us any more.
> 
> I've long since decided that there's no point to making "-pre". What's the 
> difference between a "-pre" and a daily -bk snapshot? Really?
> 
> So when I do a release, it _is_ an -rc. The fact that people have trouble 
> understanding this is not _my_ fault.

What is this whole thread all about then?

It might still be worth a try, especially since so many people are 
convinced this is the way to go (your fault or not is not the point).


Nicolas

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Nicolas Pitre wrote:
> 
> It might still be worth a try, especially since so many people are 
> convinced this is the way to go (your fault or not is not the point).

Making releases is actually a fair bit of work. Not the script itself, but 
just deciding and trying to synchronize. The fatc that people won't really 
appreciate it anyway, and just complain about "that's not stable anyway" 
just makes me even less interested.

The undeniable _fact_ in this discussion is that we're merging a lot of
patches - which is good, because that's how we keep 2.6.x relevant, and
not just a dead branch. And that is also what makes it fundamentally
different from 2.4.x, and I think a lot of people are just ignoring that
fact.

If people want a stable branch, they have to freeze their own thing. I and
Andrew do a lot of work to keep 2.6.x releases high-quality, and I think
we've been very successful in it too. The _whining_ from people who don't
realize that we can't just stop running (because if we did, quality would
go _down_ when we're then overwhelmed afterwards) is really quite grating,
though.

		Linus

Re: RFD: Kernel release numbering

[Nicolas Pitre]

On Fri, 4 Mar 2005, Linus Torvalds wrote:

> 
> 
> On Fri, 4 Mar 2005, Nicolas Pitre wrote:
> > 
> > It might still be worth a try, especially since so many people are 
> > convinced this is the way to go (your fault or not is not the point).
> 
> Making releases is actually a fair bit of work. Not the script itself, but 
> just deciding and trying to synchronize. The fatc that people won't really 
> appreciate it anyway, and just complain about "that's not stable anyway" 
> just makes me even less interested.

Don't read me wrong.

It's not the work that is being done which is the problem.  To the 
contrary, the current process is really great and for one I hope 2.7.x 
will _never_ happen, and here's why:

Coming from the embedded world I can tell you that 2.5.x was simply too 
"instable" to use as a basis for a product, and communities around non 
i386 architectures simply don't have enough man power to follow two 
kernel trees (2.4.x and 2.5.x) in parallel.  The embedded world 
therefore ended up developing on 2.4.x only because that was the stable 
tree that could bring revenues to sustain said development, even if 2.4.x 
was a dead end.

Now the catch up phase on 2.6.x within the embedded world is almost done 
and 2.6.x is also where the major developments are happening.  It's 
therefore way easier for smaller communities to stay in the game since 
2.6.x is also stable enough for commercial products despite the rapid 
development actually occurring there.  There are certainly a few more 
stability glitches than you could have found in 2.4.x but overall 2.6.x 
is a much better compromise bringing much more value to us -- thanks to 
your hard work and Andrew's (and RMK's) and everybody else for making 
the current process so efficient and dynamic.

Now back to the current discussion.  What people are complaining about 
is the lack of testing on the official 2.6.x releases.  This lack of 
testing comes from the fact that your -rc releases are not seen like 
stable enough for the mass to test, and this is due mainly because the 
people outside of the development loop have no idea when you actually 
called for a patch calm down.

It's not like you don't actually call for a calm down in order to have a 
release stabilized because, as Andrew pointed out, you effectively only 
merged true bug fixes into 2.6.11-rc[45].  See? You _do_ it and you 
_did_ it already.

The only issue is to actually have way more people to jump in and try 
out kernels which are in that "calm down" phase.  And for that to happen 
you need a clear signal to the people outside the development loop who 
currently can't trust your -rc releases since they end up including more 
than just bug fixes up to a randomly chosen particular -rc.

That's why many are suggesting that you consider switching to -pre 
releases for developer sync points, and for the last -pre release where 
you call for a calm down.  Then subsequent releases are -rc releases 
with strictly bug fixes.  For example, 2.6.11-rc[123] would have been 
2.6.11-pre[123] and 2.6.11-rc[45] would have been 2.6.11-rc[12].

See how this won't change anything to your work methodology besides the 
naming?  And this has the potential of bringing more testers not closely 
following lkml or the commit log (granted that -rc becomes real 
release-candidate-bug_fix_only releases but again you do that already) 
since they'll see those -rc releases as nearly official releases.  Of 
course it might not bring the hoped result but it costs nothing to try 
it out.  That's what I meant in my previous email.

P.S.: this is not incompatible with the "sucker" tree -- in fact both 
of those things might be useful and effective for their own purpose.


Nicolas

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Fri, 2005-03-04 at 09:57 -0800, Linus Torvalds wrote:
> I've long since decided that there's no point to making "-pre". What's the 
> difference between a "-pre" and a daily -bk snapshot? Really?

-preX are milestones mainly for developers

When -preX is converted to -rc1 then it defines feature freeze and the
testing / polishing steps to the final release take place, with "serious
bugfixes only" policy.

I know you think the -rc polishing is boring, so why don't you give it
to somebody else ? 

In fact the 2.6.x.y tree is a substitution for this. So the official
2.6.X release will be considered a real release candidate within no
time.

If this is your intention, then please state it loud and clearly and use
generally known and understandable naming conventions for it.

> So when I do a release, it _is_ an -rc. The fact that people have trouble 
> understanding this is not _my_ fault.

If you are referring to rc == "ridiculous count", I agree that it is not
your fault. Its not necessary to understand that.

If you refer to rc == "release candidate", please start to act in a way
which people _can_ actually understand without reading LKML and finding
the proclamation mail, in which you declare that ridiculous count should
now be considered as a release candidate.

There is no way to change common practice by proclamation. 

tglx

Re: RFD: Kernel release numbering

[Rene Herman]

Linus Torvalds wrote:

> I've long since decided that there's no point to making "-pre". What's the 
> difference between a "-pre" and a daily -bk snapshot? Really?

The fact that not a script, but Linus Torvalds, decides that the tree is 
in a state he likes to share with others. You have been doing -pre's all 
this time, it's just that you are calling them -rc's.

> So when I do a release, it _is_ an -rc. The fact that people have trouble 
> understanding this is not _my_ fault.

You have no intent whatsoever to release your -rc1's as the next -final, 
so what is this private definition of "release candidate" we are not 
understanding?

Note, I am not complaining about 2.6. I think it's an absolute wonderful 
kernel, it works beautifully for me, I have no stability issues, but you 
indicated you wanted more testers for -rc and that's simply not going to 
happen when there aren't any real -rc's.

Rene.

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Rene Herman wrote:
>
> Linus Torvalds wrote:
> 
> > I've long since decided that there's no point to making "-pre". What's the 
> > difference between a "-pre" and a daily -bk snapshot? Really?
> 
> The fact that not a script, but Linus Torvalds, decides that the tree is 
> in a state he likes to share with others. You have been doing -pre's all 
> this time, it's just that you are calling them -rc's.

No.

I used to do "-pre", a long time ago. Exactly because they were 
synchronization points for developers.

These days, that's pointless. We keep the tree in pretty good working
order (certainly as good as my -pre's ever were) constantly, and
developers who need to can synchronize with either the BK tree or the
nightly snapshots. The fact is, 99% of the developers don't even need to 
do that, since most of the development process is quite well parallellised 
by now, and there is seldom any serious overlap.

So the point of -pre's are gone. Have people actually _looked_ at the -rc
releases? They are very much done when I reach the point and say "ok,
let's calm down". The first one is usually pretty big and often needs some
fixing, simply because the first one is _inevitably_ (and by design) the
one that gets the pent-up demand from the previous calming down period. 

But it's very much a call to "ok, guys, calm down now".

And if you aren't calming down, it's _your_ problem. Complaining about 
naming of -pre vs -rc is pointless. 

The even/odd situation would have made for a situation that some people
seem to be arguing for (more explicit calming-down period), but with the
difference that I think the odd ones should definitely have been
user-release quality already. But that one was apparently hated by so many
people that it's not even worth trying.

The fact is, there is no perfect way of doing things, and this discussion 
has degenerated into nothing but whining. Which is kind of expected, but 
let's hope that the only non-whining that came out of this (Greg & co's 
trials with 2.6.x.y) ends up being worthwhile.

		Linus

Re: RFD: Kernel release numbering

[Gene Heskett]

On Friday 04 March 2005 15:37, Linus Torvalds wrote:
[...]
>No.
>
>I used to do "-pre", a long time ago. Exactly because they were
>synchronization points for developers.
>
>These days, that's pointless. We keep the tree in pretty good
> working order (certainly as good as my -pre's ever were)
> constantly, and developers who need to can synchronize with either
> the BK tree or the nightly snapshots. The fact is, 99% of the
> developers don't even need to do that, since most of the
> development process is quite well parallellised by now, and there
> is seldom any serious overlap.

And I think your use of bitkeeper is largely responsible for that.

>So the point of -pre's are gone. Have people actually _looked_ at
> the -rc releases? They are very much done when I reach the point
> and say "ok, let's calm down". The first one is usually pretty big
> and often needs some fixing, simply because the first one is
> _inevitably_ (and by design) the one that gets the pent-up demand
> from the previous calming down period.
>
>But it's very much a call to "ok, guys, calm down now".
>
>And if you aren't calming down, it's _your_ problem. Complaining
> about naming of -pre vs -rc is pointless.
>
>The even/odd situation would have made for a situation that some
> people seem to be arguing for (more explicit calming-down period),
> but with the difference that I think the odd ones should definitely
> have been user-release quality already. But that one was apparently
> hated by so many people that it's not even worth trying.
>
>The fact is, there is no perfect way of doing things, and this
> discussion has degenerated into nothing but whining. Which is kind
> of expected, but let's hope that the only non-whining that came out
> of this (Greg & co's trials with 2.6.x.y) ends up being worthwhile.
>
>  Linus
One last Q I guess.  When was the last time somebody flushed a bug out 
of forcedeth?  I built a kernel last night after turning off the 
broken flag, and when I rebooted to it this morning I was surprised 
to see that because its still marked experimental, I had no 
networking.  And when I went to turn that back on, I also had to go 
turn that back on seperately.

IMO, no usefull purpose is achieved by keeping it experimental after 
the amount of time thats gone by with 1/4 of the world whose mobo has 
an NForce2 chipset on it, using that as their networking driver.

My $0.02.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: RFD: Kernel release numbering

[Adrian Bunk]

On Fri, Mar 04, 2005 at 12:37:05PM -0800, Linus Torvalds wrote:
>...
> I used to do "-pre", a long time ago. Exactly because they were 
> synchronization points for developers.
>...
> So the point of -pre's are gone. Have people actually _looked_ at the -rc
> releases? They are very much done when I reach the point and say "ok,
> let's calm down". The first one is usually pretty big and often needs some
> fixing, simply because the first one is _inevitably_ (and by design) the
> one that gets the pent-up demand from the previous calming down period. 
> 
> But it's very much a call to "ok, guys, calm down now".

My impression about your releases is that -rc1 is a first snapshot, but 
there are still invasive changes until -rc3 or -rc4 when you _really_ 
say "only obvious bug fixes will be accepted".

It's _only about naming_:

Name the first one -pre1 instead of -rc1 and the snapshot you announce 
with "only obvious bug fixes will be accepted" -rc1.

It might not matter for you how it's called, but it does matter for 
other people and it doesn't cost you any extra effort.

> And if you aren't calming down, it's _your_ problem. Complaining about 
> naming of -pre vs -rc is pointless. 
>...

If I send a non-bugfix patch to Marcelo after 2.4.30-rc1 he'll say:
  "Thanks, queued for 2.4.31 ."

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFD: Kernel release numbering

[Pavel Machek]

Hi!

> > The fact that not a script, but Linus Torvalds, decides that the tree is 
> > in a state he likes to share with others. You have been doing -pre's all 
> > this time, it's just that you are calling them -rc's.
> 
> No.
> 
> I used to do "-pre", a long time ago. Exactly because they were 
> synchronization points for developers.
> 
> These days, that's pointless. We keep the tree in pretty good working
> order (certainly as good as my -pre's ever were) constantly, and
> developers who need to can synchronize with either the BK tree or the
> nightly snapshots. The fact is, 99% of the developers don't even need to 

Actually, sync to -pre is easier than sync to -bk snapshot:
* you get incremental patches from kernel.org
* there's reasonable number of pre-s so that you can be up-to-date without
syncing each day

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: RFD: Kernel release numbering

[David Lang]

On Fri, 4 Mar 2005, Rene Herman wrote:

> Linus Torvalds wrote:
>
>> I've long since decided that there's no point to making "-pre". What's the 
>> difference between a "-pre" and a daily -bk snapshot? Really?
>
> The fact that not a script, but Linus Torvalds, decides that the tree is in a 
> state he likes to share with others. You have been doing -pre's all this 
> time, it's just that you are calling them -rc's.

remember that there are the nightly CVS dumps and patches being created as 
well.

from my point of view it appears that when Linus releases -rc1 he is 
hopeing that it's actually going to be final, but since nobody bothers to 
test before that it has never actually been the case. As a result 
additional changes need to be done and Linus chooses to fix it by moving 
forward and doing additional fixes rather then by reverting patches. He 
does allow some additional patches to move in as well for a little while, 
but all of them are expected to be fixes.

David Lang


-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: RFD: Kernel release numbering

[Nick Piggin]

Andrew Morton wrote:
> Thomas Gleixner <tglx@linutronix.de> wrote:

> 
>>I don't see that the releases are stable. They are defined stable by
>>proclamation. 
> 
> 
> If they were stable we'd release the darn things!  *obviously* -rc kernels
> are expected to still have problems.
> 

Release the -rc kernel when it is stable. Then people will test them,
and then they'll hopefully catch the small annoyances that give our
real releases a bad reputation.

> -rc just means "please start testing", not "deploy me on your corporate
> database server".
> 
> People are smart enough to know that -rc3 will be less buggy than -rc1.
> 
> And if they're worried about bugs then why are they running -rc's at all?
> 

Well they aren't in the current scheme. When doing real release candidates,
they'll test* because they _are_ worried about bugs, and testing an -rc is
an easy way to get all your little compilation problems fixed, and all your
strage usb drivers working again for the realease. And without someone
rewriting the page table code in the meantime.

I could be completely wrong, but that's my feeling.

* Maybe not on their live corporate database server though

Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Fri, 2005-03-04 at 00:54 -0800, Andrew Morton wrote:
> > I don't see that the releases are stable. They are defined stable by
> > proclamation. 
> 
> If they were stable we'd release the darn things!  

You are hitting the point. We release the darn things. 2.6.11 is
released and it is not stable enough, because it had not enough test
coverage.

> *obviously* -rc kernels are expected to still have problems.
>
> -rc just means "please start testing", not "deploy me on your corporate
> database server".

Yes this should be the meaning of -rc. But in reality it is not. And
thats the damned reason why people are ignoring -rc releases.

> People are smart enough to know that -rc3 will be less buggy than -rc1.

And they are smart enough to know that -rc3 is a complete different
beast as -rc1 and not a stabilized version of -rc1.

> > This 2.6.x.y tree will change nothing as long as the underlying problem
> > is not solved.
> 
> What underlying problem?  The fact that -rc1 comes a bit too early?  Spare
> me, that's just a nothing.  Anyone who is testing -rc kernels knows the
> score.

We are talking about how to convince more people to test -rc kernels in
order to have a stable release version. Those who are testing current -
rc kernels are not enough people to give this a good coverage.

> That being said, yes, I agree that we should use 2.4-style -pre and -rc. 
> But changing the names of things won't change anything.

Ack. Changing only the names is nonsense. You have to change the way it
works. Jeff pointed out correctly that this is also a human
communication problem. We have managed to scare people off testing -rc
kernels. So we end up with a release 2.6.X where people actually start
testing and complaining. Now we want to maintain a 2.6.X.Y tree which
fixes those problems. Thats plain wrong IMNSHO, because it moves out the
-rc phase to a 2.6.X.Y tree without real target. Linus called it sneaky
and thats what it is. A sneaky gimmick. People will debunk this.

We have different goals to achieve:

- Stable kernel releases
- Broad testing coverage of -rc versions
- Ongoing stable development
- Bleeding edge development

This is nothing new. Thats a _normal_ workflow in projects whether OSS
or commercial.

-mm             -Linus          -release
 |                |
 |--------------->|
 |                |
 |                pre1
 |                |
 |                pre..
 |                |
 |                preX ---------->rc1
 |                |                |
 |--------------->|               rc..
 |                |                |
 |                pre1            rcX = stable release
 |                |                |
 |                |               stable + security fixes
 |                pre..
 |                |
 |                preX ---------->rc1
 |                |                |
 |--------------->|               rc..
 |                |                |
 |                pre1            rcX = stable release
 |                |                |
 |                |               stable + security fixes
 |                pre..
 	
This is a clear seperation and solves several problems

- Linus must not do the boring real -rc steps
- -rc versions are likely to get good testing coverage
- Release versions will be stable
- Development is continous
- Release cycles will be more frequently

> > A clearly defined switch from -preX to -rc will give the avarage user a
> > clear sign where he might jump in and test. 
> 
> The average user has learnt "rc1 == pre1".  I don't expect that it matters
> much at all.

Yes thats the point. He has learnt that and therefor he is ignoring
_all_ -rc versions.

tglx

Re: RFD: Kernel release numbering

[David Greaves]

>-rc just means "please start testing", not "deploy me on your corporate
>database server".
>  
>
Does it? Where on www.kernel.org does it say that?


Since people's trust was lost (a bit) when the -rc convention was 
"embraced and extended", it seems like it would be a good idea to 
_explicitly publish_ (and promote) the definitions (when they are agreed).

I am assuming that the problem is still essentially:
 "We need more testers"

And that one objective of this discussion is actually to clarify how the 
numbering scheme presents the risks and rewards associated with running 
a particular kernel? (yes, you're also sorting out development workflow 
but that's another issue)


Since the "show us the code" principle applies, I'm trying to draft some 
text that I propose linking to from a prominent place on www.kernel.org
(yes it may be hosted elsewhere)

My gut-feel working title was : "Our Promises To The Linux Kernel 
Community" - but I think that's going to be wrong :)

Here's the very very draft text - I've barely proof read it and I've not 
researched the process so I know it's not expressed well.
It's the kind of thing I'd want to read to assess which kernels to test 
- hell, right now it's not even obvious if you _want_ me to test them.

--------------------------------------

Background
The 'vanilla' linux kernel produced by Linus et al isn't for everyone.
Many, indeed most, users should be using the kernel that comes with 
their distribution (Debian, Fedora etc)
However, if _everyone_ did that then no-one would find the problems with 
the kernel - the 'many eyes' part of the FOSS community is essential - 
and you can be an active part of it!

This document aims to describe how people of different skill and 
experience levels can help.
Be warned - it can be hard work - but that's what makes it worthwhile.

The Problem
The kernel developers let you grab hold of a kernel tree at any time - 
which one should you use?

The key to all this is in the numbering; it indicates what stage of 
development that particular version of the kernel is at now.
Broadly the way it works is this(?):
* Developers send code and fixes to maintainers who have their own tree
* Maintainers keep an eye on the code quality and send it through to 
Linus when they think it's ready
* Linus holds the main, stable(ish) tree
* Distributions take a stable-ish tree and may apply their own changes 
and back-port bugs to try and get a very stable tree

Kernel Numbering
The kernel numbering usually looks like: 2.6.10; The X.Y.Z should be 
read as:
* X and Y indicate the main and sub versions of the kernel - probably 
'2.6' for quite a while yet.
* The Z indicates incremental 'releases' that the kernel community 
(Linus) think are OK to use in most 'production' environments.

But the beauty (and complexity) of the linux kernel is that you get to 
see it whilst it's putting its make-up on!!

Applying the Make-up - Developer Kernels
There are lots of developers who have their own 'bk' trees of the kernel 
that have changes applied from minute to minute.
Eventually the changes in these trees settle down a bit and elements of 
the trees are pulled into a major maintainers tree (eg -mm,  Andrew 
Morton's tree - more later)
Finally they're pulled into Linus' tree.

-pre Kernels
After a bit Linus feels that there have been quite a few changes and 
decides to get everyone back on the same page so he releases 2.6.x-pre1.
This is a developers release.
It won't be announced on linux-kernel-announce.
It will have bugs but it should compile cleanly and shouldn't corrupt 
your data (unless noted). It's very useful if you're helping to test 
some new hardware or feature and you don't mind if the machine crashes 
(maybe a lot - and maybe kills your data too!).
The cycle repeats through -pre2, -pre3 etc until Linus feels that it's 
time to think about a new proper release. During these cycles, 
developers can add new features and things that used to work may break.

So he takes the last -preN release and re-releases it as -rc1 ... a 
Release Candidate.

-rc Kernels
At this point he's saying that he'd _like_ to release it so it won't 
corrupt your data and the developers can't find any obvious bugs (unless 
noted) but there  *will* be some 'cos it's not been tested on every 
machine on the planet!
This is a testing release.
It will be announced on linux-kernel-announce.
You should be able to run it on normal hardware without crashes or any 
other problems. But you're part of the test team so there is a risk.
This cycle repeats through -rc2, -rc3 etc. During these cycles, _NO_ new 
features will be added. Only bugs will be fixed and it should be very 
rare for something that worked in -rcX to fail in -rcX+1.
When the bug reports stop appearing it's time for a release.
Linus will take the last -rcN and re-release it as 2.6.x (possibly with 
some errata of known bugs)

2.6.x.y Kernels
But it doesn't stop there :)
There may still be unknown bugs because no-one's tested a particular 
combination of components that triggers them.
So if a fix for a simple bug is discovered a group of people will review 
it and, if it's deemed to be very safe they will apply it to the 2.6.x 
and release 2.6.x.1 (or patches or whatever - yet to be agreed AFAICS)
It will be announced on linux-kernel-announce.

Wait, There's More...
Remember about the maintainers kernels? -mm and the like?
Well there's a list of them <here - where?> which explains how to get 
them and what their 'manifesto' is.
For the more sophisticated of you out there it may be worth trying out 
the -mm kernel (or a friend); they follows the same basic lines as 
Linus' - (in a sense they're based on them - but they are the leading 
edge of the linux kernel and have extra features and performance 
tweaks). They are often more experimental (and risky) than Linus' kernel 
though some strive to be more stable - read the manifesto to find out more.
They will be announced on their own lists (see manifesto)


So What To Do?
Join in - run the latest kernel and report back bugs - the kernel 
community _do_ want your help.
Just make sure you understand the risks and protect yourself appropriately.


To be continued... (mention kernelnewbies or other links, automating the 
process, ketchup etc - thanks Horst, Jan Dittmer, Andrew James Wade)


David
PS To be clear, I'm contributing this text in case anyone feels they can 
use it in any way.

Re: RFD: Kernel release numbering

[Lee Revell]

On Thu, 2005-03-03 at 16:03 -0800, Andrew Morton wrote:
> Or, to put it another way, we're getting a small number of irritating
> regressions, mainly in device drivers which is giving the whole thing a bad
> rep.  Is there some way in which we can fix that problem without
> reinventing the whole world?

This seems to be a damn hard problem.  For example I can't think of any
reasonable release candidate process that would have prevented that
guy's sound problem with the Thinkpad and the docking station.  Without
comprehensive hardware documentation, as long as there are more
different types of hardware then there are people who can hack drivers,
I think this will be an issue.

Lee

Re: RFD: Kernel release numbering

[Alan Cox]

On Iau, 2005-03-03 at 23:17, Andrew Morton wrote:
> Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
> development skills - it's just patchmonkeying the things which maintainers
> send him.

I would disagree, and I suspect anyone else who has maintained a distro
stable kernel would likewise. It needs one or more people who know who
to ask about stuff, are careful, have a good grounding in bug spotting,
races, common mistakes and know roughly how all the kernel works.
Maintainers aren't very good at it in general and they don't see
overlaps between areas very well.

Realistically you have to do stuff like read each Linus checkin and
classify it.

Al Viro is probably the perfect 2.6.x.y maintainer but I doubt he'd want
to do it.

Re: RFD: Kernel release numbering

[Andrew Morton]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Iau, 2005-03-03 at 23:17, Andrew Morton wrote:
> > Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
> > development skills - it's just patchmonkeying the things which maintainers
> > send him.
> 
> I would disagree, and I suspect anyone else who has maintained a distro
> stable kernel would likewise. It needs one or more people who know who
> to ask about stuff, are careful, have a good grounding in bug spotting,
> races, common mistakes and know roughly how all the kernel works.
> Maintainers aren't very good at it in general and they don't see
> overlaps between areas very well.
> 

That is all inappropriate activity for a 2.6.x.y tree as it is being
proposed.

Am I right?  All we're proposing here is a tree which has small fixups for
reasonably serious problems.  Almost without exception it would consist of
backports.

Re: RFD: Kernel release numbering

[Jeff Garzik]

Andrew Morton wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
>>On Iau, 2005-03-03 at 23:17, Andrew Morton wrote:
>>
>>>Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
>>>development skills - it's just patchmonkeying the things which maintainers
>>>send him.
>>
>>I would disagree, and I suspect anyone else who has maintained a distro
>>stable kernel would likewise. It needs one or more people who know who
>>to ask about stuff, are careful, have a good grounding in bug spotting,
>>races, common mistakes and know roughly how all the kernel works.
>>Maintainers aren't very good at it in general and they don't see
>>overlaps between areas very well.
>>
> 
> 
> That is all inappropriate activity for a 2.6.x.y tree as it is being
> proposed.
> 
> Am I right?  All we're proposing here is a tree which has small fixups for
> reasonably serious problems.  Almost without exception it would consist of
> backports.

"thru-ports":  commit to linux-2.6.x.y and get Linus to pull.

	Jeff

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> > That is all inappropriate activity for a 2.6.x.y tree as it is being
>  > proposed.
>  > 
>  > Am I right?  All we're proposing here is a tree which has small fixups for
>  > reasonably serious problems.  Almost without exception it would consist of
>  > backports.
> 
>  "thru-ports":  commit to linux-2.6.x.y and get Linus to pull.

But a subset of these fixes (such as Olaf's ppc raid6 fix) are
not-for-Linus.

Otherwise I guess it'll work - we can try it and see.

Can we get a commits-list running for linux-release please?

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
>  > Am I right?  All we're proposing here is a tree which has small fixups for
>  > reasonably serious problems.  Almost without exception it would consist of
>  > backports.
> 
>  "thru-ports":  commit to linux-2.6.x.y and get Linus to pull.

This means that for patches which didn't come through -mm, their first
exposure in a public tree will be when they pop up in our "most stable"
tree.  That's backwards.

However it should be manageable, as long as linux-release is constrained to
obviously-correct and its-no-more-broken-now-than-it-used-to-be patches. 

Re: RFD: Kernel release numbering

[Alan Cox]

On Gwe, 2005-03-04 at 05:34, Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> This means that for patches which didn't come through -mm, their first
> exposure in a public tree will be when they pop up in our "most stable"
> tree.  That's backwards.

Its irrelevant. Most of the "must fix" items are security. They don't
have a convenient testing life cycle. Many of the others are things that
need a prompt fix and the same problem applies.

After all if it was in -mm then someone knew about it and would have
said "this has to make base before its released"

> However it should be manageable, as long as linux-release is constrained to
> obviously-correct and its-no-more-broken-now-than-it-used-to-be patches. 

And occasionally it will be wrong. It happens. Linus released 2.4.15,
I've released -ac patches and stuff that needed immediate "oh duh, try
the next one"
results. The important thing is that there is a base 'stable' release
that is almost always stable. That is as good as you'll get.

Alan

Re: RFD: Kernel release numbering

[Alan Cox]

On Gwe, 2005-03-04 at 02:28, Andrew Morton wrote:
> > I would disagree, and I suspect anyone else who has maintained a distro
> > stable kernel would likewise. It needs one or more people who know who
> > to ask about stuff, are careful, have a good grounding in bug spotting,
> > races, common mistakes and know roughly how all the kernel works.
> > Maintainers aren't very good at it in general and they don't see
> > overlaps between areas very well.
> > 
> That is all inappropriate activity for a 2.6.x.y tree as it is being
> proposed.
> 
> Am I right?  All we're proposing here is a tree which has small fixups for
> reasonably serious problems.  Almost without exception it would consist of
> backports.

Almost without exception maintainers will forget the backport (there are
some notable exceptions). Almost without exception maintainers will not
be aware that their backport fix clashes with another fix because that
isn't their concern.

Linus will try and sneak stuff in that is security but not mentioned
which has to be dug out (because the bad guys read the patches too).

And finally Linus throws the occasional gem into the backporting mix
because he will (rightly) do the long term fix that rearranges a lot of
code when the .x.y patch needs to be the ugly band aid.

So for example Linus will happily changed remap_vm_area to fix a
security bug by changing the API entirely and making it do some other
things. Or in the case of the exec bug he did a fix that defaulted any
missed fixes to unsafe. Fine for upstream where the goal is cleanness,
bad for .x.y because the arch people hadn't caught up and did have
remaining holes.

You also have to review the dependancy tree for a backport and what was
tested - so I skipped the NFS df fix as one example as it had never been
tested standalone only on a pile of other NFS fixes.

Alan

Re: RFD: Kernel release numbering

[Andrew Morton]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>  Almost without exception maintainers will forget the backport (there are
>  some notable exceptions). Almost without exception maintainers will not
>  be aware that their backport fix clashes with another fix because that
>  isn't their concern.
> 
>  Linus will try and sneak stuff in that is security but not mentioned
>  which has to be dug out (because the bad guys read the patches too).
> 
>  And finally Linus throws the occasional gem into the backporting mix
>  because he will (rightly) do the long term fix that rearranges a lot of
>  code when the .x.y patch needs to be the ugly band aid.
> 
>  So for example Linus will happily changed remap_vm_area to fix a
>  security bug by changing the API entirely and making it do some other
>  things. Or in the case of the exec bug he did a fix that defaulted any
>  missed fixes to unsafe. Fine for upstream where the goal is cleanness,
>  bad for .x.y because the arch people hadn't caught up and did have
>  remaining holes.
> 
>  You also have to review the dependancy tree for a backport and what was
>  tested - so I skipped the NFS df fix as one example as it had never been
>  tested standalone only on a pile of other NFS fixes.

I think you're assuming that 2.6.x.y will have larger scope than is intended.

Re: RFD: Kernel release numbering

[Alan Cox]

On Gwe, 2005-03-04 at 11:28, Andrew Morton wrote:
> I think you're assuming that 2.6.x.y will have larger scope than is intended.

The examples I gave for remap_vm_area and exec are both from real world
"gosh look I am root isn't that fun" type security holes. If that is
outside the scope of 2.6.x.y then you need to go back to the drawing
board.

Re: RFD: Kernel release numbering

[Andrew Morton]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Gwe, 2005-03-04 at 11:28, Andrew Morton wrote:
> > I think you're assuming that 2.6.x.y will have larger scope than is intended.
> 
> The examples I gave for remap_vm_area and exec are both from real world
> "gosh look I am root isn't that fun" type security holes. If that is
> outside the scope of 2.6.x.y then you need to go back to the drawing
> board.

Well *obviously* things like that are in scope.

It's hardly likely that "maintainers will forget the backport" in that
case, is it?

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Alan Cox wrote:
>
> On Gwe, 2005-03-04 at 11:28, Andrew Morton wrote:
> > I think you're assuming that 2.6.x.y will have larger scope than is intended.
> 
> The examples I gave for remap_vm_area and exec are both from real world
> "gosh look I am root isn't that fun" type security holes. If that is
> outside the scope of 2.6.x.y then you need to go back to the drawing
> board.

Alan, I think your problem is that you really think that the tree _I_ want 
is what _you_ want.

I look at this from a _layering_ standpoint. Not from a "stable tree"  
standpoint at all.

We're always had the "wild" kernels, and 90% of the time the point of the
"wild" kernels has been to let people test out the experimental stuff,
that's not always ready for merging. Like it or not, I've considered even
the -ac kernel historically very much a "wild" thing, not a "bugfixes" 
thing.

What I'd like to set up is the reverse. The same way the "wild" kernels
tend to layer on top of my standard kernel, I'd like to have a lower
level, the "anti-wild" kernel.  Something that is comprised of patches
that _everybody_ can agree on, and that doesn't get anything else. AT ALL.

And that means that such a kernel would not get all patches that you'd 
want. That's fine. That was never the aim of it. The _only_ point of this 
kernel would be to have a baseline that nobody can disagree with.

In other words, it's not a "let's fix all serious bugs we can fix", but a 
"this is the least common denominator that is basically acceptable to 
everybody, regardless of what their objectives are".

So if you want to fix a security issue, and the fix is too big or invasive 
or ugly for the "least common denominator" thing, then it simply does not 
_go_ into that kernel. At that point, it goes into an -ac kernel, or into 
my kernel, or into a vendor kernel. See?

The point is not to make a perfect kernel. Two reasons:

 - aiming for perfect doesn't work, and would just stress out the 
   maintainer of the sucker-tree. In contrast, aiming for "is this 
   _totally_ non-offensive to everybody" is something that can be done by 
   consensus fairly easily - it's enough that one person says "no", and 
   the issue is solved. No stress, no gray areas.

 - perfect doesn't _exist_. As you yourself point out, different people 
   have different goals. The development kernel is not supposed to just
   revert a patch unless the patch itself was fundamentally flawed. And
   the development kernel is generally much more geared towards "let's fix
   this right"  rather than "let's apply an ugly bandaid that makes it 
   harder to fix it properly later".

So as long as you see this sucker-tree as a _replacement_ for the -ac 
kernels, you will _never_ be happy. But my whole point is that it's not a 
replacement at all. It's a starting point for others. It's something that 
should be fairly easy to set up, and exactly _because_ the aim is to be 
inoffensive, it's somethign where people can basically rely on the fact 
that they don't have to think about things that go into the sucker-tree: 
we'll set it up so that it's an acceptable base-line for everybody.

Is it an acceptable _solution_ for everybody? No. It's not even aiming to
be. It's aiming to be a "let's get at 45% of the way, with 5% of the
effort". And the way we make the effort low is by having the hard rules, 
and having the "single vote throws it out" approach. That's also what 
limits the tree, but hey, that's ok.

So how do you get to your solution? You could have a "slightly more wild" 
tree that takes the "other" patches. That "slightly more wild" tree would 
be for somebody _else_ to maintain (ie it might be you), and that would be 
the fixes that aren't acceptable to everybody. 

In other words: I'm talking about scalability of development, not about 
fixing every single serious bug. I think this one will catch the 
embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh, 
we had this race forever, but we never even realized", but it wouldn't 
solve the ones where we had "damn, we did the locking wrong".

But let's face it - _most_ security bugs are of the "duh" variety. That's 
easy to overlook, because those are the ones you don't worry about, but 
the fact is, if we can get a tree that makes it possible for most people 
to just get those fixes without thinking about it, then that's a _good_ 
thing.

So think of it as a piece in the puzzle, not the whole picture.

			Linus

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Linus Torvalds wrote:
> 
> In other words: I'm talking about scalability of development, not about 
> fixing every single serious bug. I think this one will catch the 
> embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh, 
> we had this race forever, but we never even realized", but it wouldn't 
> solve the ones where we had "damn, we did the locking wrong".

Btw, I also think that this means that the sucker-tree should never aim to 
be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the 
sucker tree would be _included_ in that release (and it may indeed be all 
of it - most of the time it probably would be), but we should not assume 
that "2.6.x.y" _has_ to be just the sucker tree.

We might want to release a "2.6.x.y" that contains a patch that is too big
or too intrusive (or otherwise controversial) to really be valid in the
sucker-tree.

And I'd want that to be very much explicit in the "charter" for the
sucker-tree. Exactly because the whole point (to me, at least) is to make 
it _easy_ to maintain. There should never be any discussion at all about 
patches: either they are universally loved, or they are not. And if the 
sucker-tree is seen as a 2.6.x.y release tree, then that will _inevitably_ 
mean that people will start discussing whether one patch or the other is 
supposed to go in.

My personal gut feeling is that 90% of the patches I _ever_ see are
"obvious". If we also cut them down to "must fix an oops/hang/roothole", I 
think we'll actually get quite far with a sucker tree. We'll never get all 
the way, but exactly because the tree wouldn't _try_ to get all the way, 
it would be a lot easier to maintain.

And let's face it, just getting 50% of the way and having somethign that 
catches the brown-paper-bag stuff so that nobody else every needs to worry 
about them is really worthwhile.

		Linus

Re: RFD: Kernel release numbering

[Greg KH]

On Fri, Mar 04, 2005 at 10:27:37AM -0800, Linus Torvalds wrote:
> Btw, I also think that this means that the sucker-tree should never aim to 
> be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the 
> sucker tree would be _included_ in that release (and it may indeed be all 
> of it - most of the time it probably would be), but we should not assume 
> that "2.6.x.y" _has_ to be just the sucker tree.

Ah crap, I just called the first release of such a tree, 2.6.11.1.

> We might want to release a "2.6.x.y" that contains a patch that is too big
> or too intrusive (or otherwise controversial) to really be valid in the
> sucker-tree.

Are you sure we would ever do that?  We never have before...

I think we should call it the 2.6.x.y tree, as that way users can easily
understand it.  They see it and say, "Ah look, it's 2.6.x with only
real bugfixes in it."  It's very simple to explain to others.

And if you disagree, what _should_ we call it?  "-sucker" isn't good, as
it only describes the people creating the tree, not any of the users :)

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Randy.Dunlap]

Greg KH wrote:
> On Fri, Mar 04, 2005 at 10:27:37AM -0800, Linus Torvalds wrote:
> 
>>Btw, I also think that this means that the sucker-tree should never aim to 
>>be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the 
>>sucker tree would be _included_ in that release (and it may indeed be all 
>>of it - most of the time it probably would be), but we should not assume 
>>that "2.6.x.y" _has_ to be just the sucker tree.
> 
> 
> Ah crap, I just called the first release of such a tree, 2.6.11.1.

Darn, I thought that we were converging to that also....
unless we can get back to -pre and -rc naming.

> 
>>We might want to release a "2.6.x.y" that contains a patch that is too big
>>or too intrusive (or otherwise controversial) to really be valid in the
>>sucker-tree.
> 
> 
> Are you sure we would ever do that?  We never have before...
> 
> I think we should call it the 2.6.x.y tree, as that way users can easily
> understand it.  They see it and say, "Ah look, it's 2.6.x with only
> real bugfixes in it."  It's very simple to explain to others.
> 
> And if you disagree, what _should_ we call it?  "-sucker" isn't good, as
> it only describes the people creating the tree, not any of the users :)

-fixup or -fixes maybe.  x.y is OK too.  :)

Can/will/should it also include *required* (showstopper) build fixes,
if there are any of those?

-- 
~Randy

Re: RFD: Kernel release numbering

[Greg KH]

On Fri, Mar 04, 2005 at 10:59:54AM -0800, Randy.Dunlap wrote:
> 
> Can/will/should it also include *required* (showstopper) build fixes,
> if there are any of those?

I think so, the ppc fix is such a thing.  But not for things marked
CONFIG_BROKEN :)

thanks,

greg k-h

RE: RFD: Kernel release numbering

[Hua Zhong]

> -fixup or -fixes maybe.  x.y is OK too.  :)

How about Service Pack? 

:joke:

I could never understand why we have confused users in the naming in 2.6
serials and are trying to confuse them even more..

Hua

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Fri, 4 Mar 2005, Greg KH wrote:
> 
> Ah crap, I just called the first release of such a tree, 2.6.11.1.

I don't think any of us really _know_ where we are going, and we're all 
just discussing our personal ideas of what should work.

As such, I think experimentation comes into it. Dammit, I want everybody
to know that I'm perfectly happy to change my mind and admit when I'm
wrong. I may not like it any more than the average person, but if the
2.6.x.y approach ends up working fine, why not? 

Iow, let's be open to some experimentation, and see what actually works.

> Are you sure we would ever do that?  We never have before...

Well, I think we've only ever done a single 2.6.x.y release before, and I 
think it's good that you try to make more of them. I'm not at all unhappy 
with your 2.6.11.1 - I just think that there might be more automation 
involved in the long run.

But automation takes time to build up and learn, and in the meantime doing 
it by hand and learning early is definitely the right thing to do. Maybe 
you doing it by hand just makes it clear that I was wrong about the need 
for some strict rules that are automatically enforced in the first place.

> And if you disagree, what _should_ we call it?  "-sucker" isn't good, as
> it only describes the people creating the tree, not any of the users :)

Let's try with the 2.6.x.y numbering scheme, it's simple, and maybe it 
ends up being sufficient. I just wanted to bring up the point that I don't 
think the sucker tree _has_ to be seen as a 2.6.x.y tree at all.

		Linus

Re: RFD: Kernel release numbering

[Greg KH]

On Fri, Mar 04, 2005 at 11:12:22AM -0800, Linus Torvalds wrote:
> But automation takes time to build up and learn, and in the meantime doing 
> it by hand and learning early is definitely the right thing to do. Maybe 
> you doing it by hand just makes it clear that I was wrong about the need 
> for some strict rules that are automatically enforced in the first place.

Heh, it will have to be done by hand for a while, as I don't think any
of us want to write a kernel-patch-managemement-system in our spare
time.  Although, I do know that osdl's PLM at one time was planned to be
such a tool, I'll go kick the developers over there to see what they
say...

> > And if you disagree, what _should_ we call it?  "-sucker" isn't good, as
> > it only describes the people creating the tree, not any of the users :)
> 
> Let's try with the 2.6.x.y numbering scheme, it's simple, and maybe it 
> ends up being sufficient. I just wanted to bring up the point that I don't 
> think the sucker tree _has_ to be seen as a 2.6.x.y tree at all.

Fair enough, I'll stick with 2.6.x.y, as I think it's a good
representation of what people expect.  If people start objecting, I'm
always open for change.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Jeff Garzik]

Greg KH wrote:
> On Fri, Mar 04, 2005 at 11:12:22AM -0800, Linus Torvalds wrote:
>>Let's try with the 2.6.x.y numbering scheme, it's simple, and maybe it 
>>ends up being sufficient. I just wanted to bring up the point that I don't 
>>think the sucker tree _has_ to be seen as a 2.6.x.y tree at all.
> 
> 
> Fair enough, I'll stick with 2.6.x.y, as I think it's a good
> representation of what people expect.  If people start objecting, I'm
> always open for change.


So far, 2.6.11.1 was what I was hoping, and expecting, it would be.

	Jeff

Re: RFD: Kernel release numbering

[Alan Cox]

On Gwe, 2005-03-04 at 18:18, Linus Torvalds wrote:
> Alan, I think your problem is that you really think that the tree _I_ want 
> is what _you_ want.

No I think you just misunderstood the point I was trying to make. They
are different trees and the difference is what stops you just doing the
layering Andrew seemed to think would work.

> I look at this from a _layering_ standpoint. Not from a "stable tree"  
> standpoint at all.

>From a layering perspective the .x.y.z kernel is a dead end fork each
2.x.y and that means it can and should make use of the ugly short term
fixes that solve problems.

> And that means that such a kernel would not get all patches that you'd 
> want. That's fine. That was never the aim of it. The _only_ point of this 
> kernel would be to have a baseline that nobody can disagree with.

Thats fine. It's a useful check, although it means we now have another
layer of obfuscation.

> In other words, it's not a "let's fix all serious bugs we can fix", but a 
> "this is the least common denominator that is basically acceptable to 
> everybody, regardless of what their objectives are".

Acceptable to whom ? Users want all the security issues fixed.

> So if you want to fix a security issue, and the fix is too big or invasive 
> or ugly for the "least common denominator" thing, then it simply does not 
> _go_ into that kernel. At that point, it goes into an -ac kernel, or into 
> my kernel, or into a vendor kernel. See?

If you put the corresponding "ugghh" fix into the 2.6.x.y sure. Thats
what I'm trying to say.

> So think of it as a piece in the puzzle, not the whole picture.

I think a lot of the folks who are using the 2.6 kernels and not using
vendor kernels have enough puzzles already 8)

Alan

Re: RFD: Kernel release numbering

[Charles Cazabon]

Linus Torvalds <torvalds@osdl.org> wrote:
> 
> What I'd like to set up is the reverse. The same way the "wild" kernels
> tend to layer on top of my standard kernel, I'd like to have a lower
> level, the "anti-wild" kernel.  Something that is comprised of patches
> that _everybody_ can agree on, and that doesn't get anything else. AT ALL.
> 
> And that means that such a kernel would not get all patches that you'd 
> want. That's fine.

Let's see if I understand your intent: this new tree would be a better base
for things like -ac than the mainline Linus kernel.  It would always be a
single short branch off the latest mainline stable kernel.  It would probably
form a good base for vendor kernels and other stability-needed kernels, but by
itself wouldn't necessarily be at that level of predictability.

Does that accurately sum up what you're trying to get across?

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:               http://pyropus.ca/software/
-----------------------------------------------------------------------

Re: RFD: Kernel release numbering

[Andres Salomon]

Clearly I picked a bad week to go on vacation..


On Fri, 04 Mar 2005
10:18:41 -0800, Linus Torvalds wrote:
[...]
> 
> Alan, I think your problem is that you really think that the tree _I_ want 
> is what _you_ want.
> 
> I look at this from a _layering_ standpoint. Not from a "stable tree"  
> standpoint at all.
> 
> We're always had the "wild" kernels, and 90% of the time the point of the
> "wild" kernels has been to let people test out the experimental stuff,
> that's not always ready for merging. Like it or not, I've considered even
> the -ac kernel historically very much a "wild" thing, not a "bugfixes" 
> thing.
> 
> What I'd like to set up is the reverse. The same way the "wild" kernels
> tend to layer on top of my standard kernel, I'd like to have a lower
> level, the "anti-wild" kernel.  Something that is comprised of patches
> that _everybody_ can agree on, and that doesn't get anything else. AT ALL.
> 

That is what I'm trying to do w/ my tree; obvious fixes only.  Most of
the patches I've included in 2.6.10-asX have been stupid build fixes, and
basic C problems (ie, deref'ing a pointer before it's been assigned).  The
main time I make exceptions for that is for security fixes.  


> And that means that such a kernel would not get all patches that you'd
> want. That's fine. That was never the aim of it. The _only_ point of
> this kernel would be to have a baseline that nobody can disagree with.
> 
> In other words, it's not a "let's fix all serious bugs we can fix", but
> a "this is the least common denominator that is basically acceptable to
> everybody, regardless of what their objectives are".
> 
> So if you want to fix a security issue, and the fix is too big or
> invasive or ugly for the "least common denominator" thing, then it
> simply does not _go_ into that kernel. At that point, it goes into an
> -ac kernel, or into my kernel, or into a vendor kernel. See?
>

This is understandable.  I have included security fixes in -as that were
non-trivial; if a 2.6.x.y tree is not willing to include them, then I
guess it won't be what I was hoping.  I had emailed Chris before going on
vacation, offering to work with him on 2.6.x.y (which would allow me to
drop -as), but if security fixes aren't a higher priority thing (even
in the face of invasive/ugly changes), then I guess there's still a need
for -as/-ac.

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Jeff Garzik wrote:
> 
> The only problem I see with this -- and its a minor problem -- is that 
> some patches that belong in the 2.6.X.Y tree go straight to you/Andrew, 
> rather than to $sucker.

Yes. I think people will have to be taught, and get used to the new world
order, and that could take a long time. And don't get me wrong, I include
myself in those people, ie it's not just that everybody else needs to
learn to Cc: the new group (I assume it's best to have a mailing alias, to
allow the thing to have multiple people involved even before it gets to
the vetting stage, and then have a _separate_ mail alias for the "vettign
group" people).

Think of how the -mm tree has evolved - with me and Andrew learning how 
the other side acts and works. This would be the same thing, except 
hopefully on a smaller scale (ie the _volume_ of patches had better be an 
order of magnited smaller not just in size but in number too). It wasn't 
just "let's set up Andrew". It was a learning experience.

And yes, we'll probably get duplicated changes, _especially_ early on. But 
at least nobody seems to hate this idea, so I think we should drop the 
original even/odd suggestion for now, and see if this would make more 
sense..

		Linus

Re: RFD: Kernel release numbering

[Steven Rostedt]

A couple of weeks ago I was at LinuxWorldExpo in Boston and was talking
to several people about the stability of the 2.6 kernel.  Every one I
talked to seemed to be nervous about using it.  Some did, and some did
not and stayed with 2.4.  But each one had a different level of faith in
which kernel to use.  The biggest complaint seems that 2.6 had taken up
the MS SP approach to patches.  This patch fixes foo bug but with bar
feature added, could introduce foo2 bug. So those I talked to really
wanted a point where only fixes to real bugs were added with no extra
features.

Although it looks like Linus has decided to go with the 2.6.x.y scheme,
I would like to say that it seems to be the perfect solution to those
that I talked to.  If Linus wants to get as many people to test the
lastest kernel, then this may help in that aspect. Some would choose the
2.6.x.0, with the excitement of the latest (but not so stable) kernel,
others may wait till 2.6.x.>5, or some other number, or more likely,
after some specified time frame.  But this allows different people to
start testing the latest kernel when they feel comfortable with it.

I would even recommend that the 2.6.x.0 be equivalent to the -rc2
kernel. So if there's some feature that you would like, in 2.6.x,
instead of asking for someone to back port it, you could just wait for
2.6.x.y where y is something you are comfortable with.  I'm sure people
will still ask, but the rule would be to tell them NO. 

The problem with 2.4 / 2.5 was that there were features in 2.5 that
people would want in 2.4 but couldn't wait a year for them. This method
would allow that time to be shortened and new features won't take
forever to get to a stable release.

So kudos to Greg. I hope that everyone supports his efforts and fights
against anyone that suggests a non essential bug fix to go into a
2.6.x.y branch. 

I know lots of people (including myself) that only use the vanilla
kernel, and never the kernel that comes from the distributor. So I hope
this helps us.  Unfortunately, I have a NVidia card, which seldom works
with the latest kernels, so I don't get to test as often as I would
like, unless I sacrifice 3D graphics.

Cheers,

-- Steve

Re: RFD: Kernel release numbering

[David Lang]

On Thu, 3 Mar 2005, Steven Rostedt wrote:

> A couple of weeks ago I was at LinuxWorldExpo in Boston and was talking
> to several people about the stability of the 2.6 kernel.  Every one I
> talked to seemed to be nervous about using it.  Some did, and some did
> not and stayed with 2.4.  But each one had a different level of faith in
> which kernel to use.  The biggest complaint seems that 2.6 had taken up
> the MS SP approach to patches.  This patch fixes foo bug but with bar
> feature added, could introduce foo2 bug. So those I talked to really
> wanted a point where only fixes to real bugs were added with no extra
> features.
>
> Although it looks like Linus has decided to go with the 2.6.x.y scheme,
> I would like to say that it seems to be the perfect solution to those
> that I talked to.  If Linus wants to get as many people to test the
> lastest kernel, then this may help in that aspect. Some would choose the
> 2.6.x.0, with the excitement of the latest (but not so stable) kernel,
> others may wait till 2.6.x.>5, or some other number, or more likely,
> after some specified time frame.  But this allows different people to
> start testing the latest kernel when they feel comfortable with it.
>
> I would even recommend that the 2.6.x.0 be equivalent to the -rc2
> kernel. So if there's some feature that you would like, in 2.6.x,
> instead of asking for someone to back port it, you could just wait for
> 2.6.x.y where y is something you are comfortable with.  I'm sure people
> will still ask, but the rule would be to tell them NO.
>
> The problem with 2.4 / 2.5 was that there were features in 2.5 that
> people would want in 2.4 but couldn't wait a year for them. This method
> would allow that time to be shortened and new features won't take
> forever to get to a stable release.

I don't think you are understanding the proposal

2.6.11.y will be released as 2.6.12 is being developed.

once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a 
_real_ mess) 2.6.11.y will not get any additional releases (2.6.12.y will 
get released instead)

as a result there will be no backports at all. if you want a feature 
that's introduced in 2.6.12 then you wait until you get a 2.6.12.y release 
that's good enough for you.

also I think the expectation is that there aren't going to be more then 
2-3 2.6.x.y releases so your comment of people waiting until y>5 won't 
apply

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: RFD: Kernel release numbering

[Steven Rostedt]

On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote:

> I don't think you are understanding the proposal
> 
You're probably right. :-)

> 2.6.11.y will be released as 2.6.12 is being developed.
> 
> once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a 
> _real_ mess) 2.6.11.y will not get any additional releases (2.6.12.y will 
> get released instead)
> 
> as a result there will be no backports at all. if you want a feature 
> that's introduced in 2.6.12 then you wait until you get a 2.6.12.y release 
> that's good enough for you.
> 
I understand the no backports.  That's a good thing.  That's what I was
trying to state (but was probably too long winded!).  Lets see if this
is what I believe is being proposed.

2.6.x would be the release with some number of features added.

2.6.x.y would include bug fixes only, that are under the strong rule of
Linus to only be things that crash/hang the machine or nasty security
exploits.

2.6.x+1 would be 2.6.x.(some y) also including features (from -rc or
-mm)

2.6.x.z (where z is greater than the above "some y") only include the
same level of fixes as with 2.6.x.y, with the parallel work of 2.6.x+1
still going on.  

Please correct me if I'm wrong here.

> also I think the expectation is that there aren't going to be more then 
> 2-3 2.6.x.y releases so your comment of people waiting until y>5 won't 
> apply
> 

Say after 2.6.x.3 has been released and 2.6.x+1 is now out, and someone
finds a rare race condition that hangs the machine.  A 2.6.x.4 would not
be released?  Actually, the >5 was pretty pointless anyway.  What I got
from talking to people is that they wanted a release that only got fixes
that would crash the machine, or cause a root exploit. That's what I
thought Linus was trying to say.

-- Steve

Re: RFD: Kernel release numbering

[David Lang]

On Thu, 3 Mar 2005, Steven Rostedt wrote:

> On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote:
>
>> I don't think you are understanding the proposal
>>
> You're probably right. :-)
>
>> 2.6.11.y will be released as 2.6.12 is being developed.
>>
>> once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a
>> _real_ mess) 2.6.11.y will not get any additional releases (2.6.12.y will
>> get released instead)
>>
>> as a result there will be no backports at all. if you want a feature
>> that's introduced in 2.6.12 then you wait until you get a 2.6.12.y release
>> that's good enough for you.
>>
> I understand the no backports.  That's a good thing.  That's what I was
> trying to state (but was probably too long winded!).  Lets see if this
> is what I believe is being proposed.
>
> 2.6.x would be the release with some number of features added.
>
> 2.6.x.y would include bug fixes only, that are under the strong rule of
> Linus to only be things that crash/hang the machine or nasty security
> exploits.
>
> 2.6.x+1 would be 2.6.x.(some y) also including features (from -rc or
> -mm)
>
> 2.6.x.z (where z is greater than the above "some y") only include the
> same level of fixes as with 2.6.x.y, with the parallel work of 2.6.x+1
> still going on.
>
> Please correct me if I'm wrong here.

this sounds like what I am understanding.

>> also I think the expectation is that there aren't going to be more then
>> 2-3 2.6.x.y releases so your comment of people waiting until y>5 won't
>> apply
>>
>
> Say after 2.6.x.3 has been released and 2.6.x+1 is now out, and someone
> finds a rare race condition that hangs the machine.  A 2.6.x.4 would not
> be released?

my understanding is that in general there would no be a 2.6.x.4 in this 
case (special cases can cause rules to be bent, a rare race condition 
probably wouldn't qualify, a remote root security hole probably would)

> Actually, the >5 was pretty pointless anyway.  What I got
> from talking to people is that they wanted a release that only got fixes
> that would crash the machine, or cause a root exploit. That's what I
> thought Linus was trying to say.

the trouble is that 'crash the machine' can include a HUGE number of the 
fixes that go into 2.6.x+1 and you just lost stability again

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: RFD: Kernel release numbering

[Steven Rostedt]

On Thu, 2005-03-03 at 13:53 -0800, David Lang wrote:

> > Actually, the >5 was pretty pointless anyway.  What I got
> > from talking to people is that they wanted a release that only got fixes
> > that would crash the machine, or cause a root exploit. That's what I
> > thought Linus was trying to say.
> 
> the trouble is that 'crash the machine' can include a HUGE number of the 
> fixes that go into 2.6.x+1 and you just lost stability again

Point taken.

Actually, I believe that you would satisfy a lot of people, just if they
know that trivial, or smaller fixes are included in the release.  If a
large change is needed, then those people waiting for a stable product
would have to wait till the release that included the big change was at
a point that was acceptable to them.

What I've heard is that people are nervous about updating a kernel for a
small fix, but must also get other features that they don't need and may
introduce more bugs.

Some IT folks I've talked to are more concerned about the security of
the system than the stability.  They can feel more comfortable when they
see a machine stay up a long time, but there can be security problems
that they can't see. They don't want anything else but the fix when one
is discovered.  Grant you that these are usually few and far between,
but this is what I've been told. Of course these people stick to a
distributor for the updates, but it would be nice to have this
capability in the kernel, for those like myself (and why I state this)
that like to tinker with the kernel, and don't use the distro's version.

-- Steve

Re: RFD: Kernel release numbering

[Stephen Hemminger]

In all this discussion, I see a couple of underlying problems. The first
is what is the definition of stability.  To many (mostly kernel developers)
the definition of stability "S" depends on number of bug reports "B":

	S(infinite) = B(0)
	S(X) > S(Y) iff B(X) < B(Y)

The problem is that the kernel community never sees many problems (filtered
through distro's), and the severity and importance of problem reports
is confused. Bug tracking could help, but it would have to be universal
and painless; bugzilla doesn't cut it.

But many end-user's and IT types seem to feel that the definition 
of stability is based on rate of change, ie patches (P) over time.
	
	S(X) > S(Y) iff P(X)/t > P(Y)/t

These are the people who can't believe 2.6 is stable because they see so
much change. Having 2.6.x.y may make this group happy, but probably only
after such a long period that the the mainline kernel is 6 months ahead.

The whole point of the continuous 2.6 process, was to avoid having the 
multiple tree backporting mess that 2.5/2.4 had, especially the distro kernels
were all some hodge-podge of 2.5 and 2.4 stuff. Fixing the same bug on multiple
branches is a fundamentally flawed process that is sure to allow some bug fixes
to be missed.

The third group are those that install release 2.6.X and have some problem;
nobody wants to believe their problem is unique. So often, the user says makes
the fallacious argument that "if I had a problem, then all users will have the
problem, therefore it is unstable." These people will never be happy, they can
stay on 2.2.

Re: RFD: Kernel release numbering

[Steven Rostedt]

On Thu, 2005-03-03 at 13:38 -0800, Stephen Hemminger wrote:
> In all this discussion, I see a couple of underlying problems. The first
> is what is the definition of stability.  To many (mostly kernel developers)
> the definition of stability "S" depends on number of bug reports "B":
> 
> 	S(infinite) = B(0)
> 	S(X) > S(Y) iff B(X) < B(Y)
> 
> The problem is that the kernel community never sees many problems (filtered
> through distro's), and the severity and importance of problem reports
> is confused. Bug tracking could help, but it would have to be universal
> and painless; bugzilla doesn't cut it.
> 
> But many end-user's and IT types seem to feel that the definition 
> of stability is based on rate of change, ie patches (P) over time.
> 	
> 	S(X) > S(Y) iff P(X)/t > P(Y)/t
> 
> These are the people who can't believe 2.6 is stable because they see so
> much change. Having 2.6.x.y may make this group happy, but probably only
> after such a long period that the the mainline kernel is 6 months ahead.
> 

As I see it, there's those that would join in at different times. If the
point was to get as many people moving to newer kernels, then this would
make the most people comfortable to try a newer kernel. Maybe not the
latest and greatest, but at least one that is closer to the newest one.

Some might join 6 months behind, others 1 month and even those at 1
week. I've talked to different people, and there are many at the 1 week
point (the ones with the most critical systems would be at the 6 month,
but the 1 weekers are the ones that would put it on a more non essential
machine). 

> The whole point of the continuous 2.6 process, 
> was to avoid having the 
> multiple tree backporting mess that 2.5/2.4 had, especially the distro kernels
> were all some hodge-podge of 2.5 and 2.4 stuff. Fixing the same bug on multiple
> branches is a fundamentally flawed process that is sure to allow some bug fixes
> to be missed.
> 

Truth be told... don't worry about backporting fixes. This is the Open
Source world, many eyes, and many developers.  When a bug is reported,
say to 2.6.x.y, then let some new kernel developer try to fix it, or
whoever. Maybe even the one who reported the problem can fix it. But for
that branch only. If this bug is in a earlier branch, then don't worry
about it until someone else hits it, or say the one who fixed it, then
goes back and checks other branches only if they want to. 

I'm saying, just have the branches available, with no guarantee that
they have all the backported bugs, since no one is going to do it. But
if someone wants it, then they can have a go at it. Maybe even a distro
might add to it.  This might just give people a central repository to
all the fixes applied to a specific branch.  Again, only bug fixes and
nothing more.

> The third group are those that install release 2.6.X and have some problem;
> nobody wants to believe their problem is unique. So often, the user says makes
> the fallacious argument that "if I had a problem, then all users will have the
> problem, therefore it is unstable." These people will never be happy, they can
> stay on 2.2.

If there problem is truly a problem and if these people are capable of
fixing it themselves or finding someone else to fix it. Then again, you
have the fix at some point available for all.

-- Steve

RE: RFD: Kernel release numbering

[Hua Zhong]

> In fact, if somebody maintained that kind of tree, especially 
> in BK, it would be trivial for me to just pull from it every once in a 
> while (like ever _day_ if necessary). But for that to work, then that 
> tree would have to be about so _obviously_ not wild patches that 
> it's a no-brainer.

Alan Cox once said he would like to do it:

    > On Mer, 2004-10-27 at 19:37, Hua Zhong wrote:
    > When I said "nobody", I really meant "top kernel developers". I have
not
    > seen anyone step up and say "I'll volunteer to maintain a 2.6 stable
    > release" hence the comment.

    I'll do it if Linus wants

Do you consider having a real stable release maintainer again?

If you want someone to do the job, give him a title. It's a thankless and
boring job, and you can't make it worse by just hiding him somewhere.

How a "stable release maintainer" works for the current model is up to you.
One thought is that he picks up 2.6.x release as a start point and takes
patches to make it stable, then releases it _himself_, not by Linus. Because
the real work is done by him and you need to give him the authority (just
like other Linux 2.x maintainers who release official kernels). But of
course you still pull from his tree to make sure the bug fixes are also
committed to mainline.

Hua

RE: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Hua Zhong wrote:
> 
> Do you consider having a real stable release maintainer again?

No, this really is a different thing.

This is not a "truly separate" parallell track, exactly because it would 
not actually get a life of its own. For it to make sense, it would not do 
any big changes, ie it would be _limited_ in a way that a real stable 
release would not. Also, since it would leave the old kernel behind when a 
new stable release comes along, it would not have any real independence in 
time either.

Now, I think this "sucker tree" I'm talking about would be a great basis 
for somebody else then taking it _further_ (ie vendor stable trees), but 
it really is a fairly small step.

> If you want someone to do the job, give him a title. It's a thankless and
> boring job, and you can't make it worse by just hiding him somewhere.

Actually, that was something I'd _avoid_ - make it non-glorious on 
purpose. In the kind of tree I envision, the _last_ thing we'd want is the 
maintainer looking at a big picture and feeling important. I'd be happiest 
if he was almost totally anonymous, because I think it's likely a boring 
job, but it's a boring job that _many_ people could do (ie to avoid 
burnign people out, make it be a stint of a couple of months, not a 
"crowning life work", and then you could probably have half a dozen people 
who are perfectly willing to take it on every once in a while.

Ie I'd organize it like some of the "checkin committees" work for other 
projects that have nowhere _near_ as much work going on as Linux has. That 
seems to work well for small projects - and we can try to keep this 
"small" exactly by having the strict rules in place that would mean that 
99% of all patches wouldn't even be a consideration.

In other words, I'm really talking about something different from what you 
seem to envision. I think we should call the tree the "sucker tree", and 
if somebody wants to make a logo for it, make it be a penguin with a 
jokers' hat: exactly to remind people that it's not about the glory.

(Maybe that's going overboard a bit ;)

		Linus

RE: RFD: Kernel release numbering

[Hua Zhong]

> In other words, I'm really talking about something different 
> from what you seem to envision. 

Indeed. What I have in mind (and suggested in the past) is that we have a
real 2.6 stable release maintainer. The only difference is that he starts
from a random 2.6.x release he picks, and releases 2.6.x.y until he thinks
stable enough, and he moves on to another 2.6.z release and start the same
work. He decides which 2.6.x to pick for the next stable release. Alan Cox
has expressed his interest in this during the last discussion but it seems
you didn't pay attention or care.

The reason that I think it's important for some other person to do this job
independently is that you are not bothered by bugfixes, which you never did
well. :) You move on to each release as you do today, with different
criteria, and someone else who can do the job better do so to stablize it.

In the end it's more like the old way of 2.5/2.4, but just with a shorter
release cycle, and the "2.6 stable release maintainer" could also continue
to pick up new 2.6.x releases to work on instead of having to be stuck on
one tree for 2 years or ever. He can say "this is the last 2.6.12.x release
and next I'll start 2.6.16.1", etc.

For this to happen the person has to be well-recognized and trusted by the
community. Alan is one of the best candidates. :) Of course, I'm not sure if
he is still interested..

Hua

Re: RFD: Kernel release numbering

[Jeff Garzik]

Hua Zhong wrote:
> The reason that I think it's important for some other person to do this job
> independently is that you are not bothered by bugfixes, which you never did
> well. :) You move on to each release as you do today, with different
> criteria, and someone else who can do the job better do so to stablize it.
> 
> In the end it's more like the old way of 2.5/2.4, but just with a shorter
> release cycle, and the "2.6 stable release maintainer" could also continue
> to pick up new 2.6.x releases to work on instead of having to be stuck on
> one tree for 2 years or ever. He can say "this is the last 2.6.12.x release
> and next I'll start 2.6.16.1", etc.
> 
> For this to happen the person has to be well-recognized and trusted by the
> community. Alan is one of the best candidates. :) Of course, I'm not sure if
> he is still interested..


I think the system we appear to have wound up with is superior:  there 
is no single 2.6.X.Y maintainer, but more a $sucker mail alias that Does 
The Right Thing.

	Jeff

RE: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Hua Zhong wrote:
> 
> Indeed. What I have in mind (and suggested in the past) is that we have a
> real 2.6 stable release maintainer. The only difference is that he starts
> from a random 2.6.x release he picks, and releases 2.6.x.y until he thinks
> stable enough, and he moves on to another 2.6.z release and start the same
> work.

This is exactly how distributions work (or are at least supposed to). As 
such, it's not something _I_ care about, except in the sense of "yes, 
that's how you guys should do it". The reason I personally don't care any 
more is that it has the back- and forward-port issues, so somebody will 
have to do that, and it sure ain't me.

Now, if you are arguing that it should be something where different 
distributions do it together and don't waste engineers on their own tree, 
I do kind of agree. "Kind of", because I think different distributions 
have different issues (like timing), and that it may well just be too much 
work to try to synchronize them and keep everybody happy.

At some point it's easier and cheaper to just "waste energy". I see my job
as giving a base-line where somebody _can_ start doing the above, but at 
some point it's out of my hands.

		Linus

Re: RFD: Kernel release numbering

[Paulo Marques]

Linus Torvalds wrote:
>[...]
> Ie I'd organize it like some of the "checkin committees" work for other 
> projects that have nowhere _near_ as much work going on as Linux has. That 
> seems to work well for small projects - and we can try to keep this 
> "small" exactly by having the strict rules in place that would mean that 
> 99% of all patches wouldn't even be a consideration.

Maybe setting up a mailing list where all the patches have to be posted 
before inclusion in this tree, would help the maintainer(s) a lot.

Since we expect little traffic (at least compared to LKML) a lot of 
developers (even "small" developers like myself) can review all the 
patches for correctness, and throw quite a few eyes on them. The more 
eyes, the less a chance for bugs to slip by.

Just a thought,

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: RFD: Kernel release numbering

[James Bourne]

On Thu, 3 Mar 2005, Linus Torvalds wrote:

> On Thu, 3 Mar 2005, Jeff Garzik wrote:
> > 
> > We have all these problems precisely because _nobody_ is saying "I'm 
> > only going to accept bug fixes".  We _need_ some amount of release 
> > engineering.  Right now we basically have none.
> 
> I agree that this is one of the main problems.
> 
> But look at how to solve it. The _logical_ solution is to have a third
> line of defense: we have the -mm trees (wild and wacky patches), and we
> have my tree (hopefully not wacky any more), and it would be good to have
> a third level tree (which I'm just not interested in, because that one
> doesn't do any development any more) which only takes the "so totally not
> wild that it's really boring" patches.
> 
> In fact, if somebody maintained that kind of tree, especially in BK, it 
> would be trivial for me to just pull from it every once in a while (like 
> ever _day_ if necessary). But for that to work, then that tree would have 
> to be about so _obviously_ not wild patches that it's a no-brainer.

Sorry, I'm just on the end of this thread but I wanted to put in my 2 bits,

I was maintaining this type of tree for 2.4 before.  It was well received by
those who used it and it was stable (ssssh, I'm still running that puppy on
a couple well hidden 7.2 servers).

The key then was to only put in patches that fixed issues.  If it was a hard
factual solution to a problem then it went into the patch.  BTW, it was just
that, a patch (or set of patches) not actually a seperate tree.  It was
completely focused on stability as that's what I needed for work at the
time.

> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.

It was good for 2.4 and I think for 2.6, the legitimacy (coming from the top
down) will be a good thing.  It wasn't as widely received in 2.4 due to it
not being "officially sanctioned"...

BTW, it's not actually that much work.  Watching the list and getting feed
back on what works and what doesn't is all that it takes.  Naturally, there
will be a couple "frell, where was I when I did that" patches but that's
life in the semi-fast lane.

This will be a good thing.

Regards
James


-- 
James Bourne                  | Email:            jbourne@hardrock.org          
UNIX Systems Administration   | WWW:           http://www.hardrock.org
Custom UNIX Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

Re: RFD: Kernel release numbering

[Bill Davidsen]

Linus Torvalds wrote:

Okay, I stayed out of this until the dust has settled, but I do have a 
few thoughts.

First is that naming is important if people are to understand the 
release system, and I think a lot of people don't. So why not:

- put out -devN kernel for testing, lots of people don't know about -bk 
or how to patch. And have the changelog list only the major new features 
and bug fixes, no author, no date, just a list of the important changes. 
That means that the user can see, not internal performance tuning and such.

- call the first rc -rc0, which indicates that only bug fixes from this 
point on, and the level of stability (no much).

I think about rc1 people would be more willing to test, and if I have a 
problem and the -dev claims a solution, I would be more willing to test, 
which might catch more of the "this crap doesn't even compile" errors.

> So let's loook at how we could set that up. We need:

>  - some very _technical_ and objective rules on patches. And they should 
>    limit the patches severely, so that people can never blame the sucker 
>    who does the job. For example, I would suggest that "size" be one hard 
>    technical rule. If the patch is more than 100 lines (with context) in
>    size, it's not trivial any more. Really. Two big screenfuls (or four, 
>    for people who still use the ISO-ANSI standard 80x24 vt100)

It's your ruleset, but I think the next rule is adequate. If there's a 
serious problem, and the solution means fixing bad locking in 50 places 
easily identified, it's probably still worth fixing if there's no 
band-aid available.

In short, trust the maintainer to make a good call on this.
> 
>    Also, I'd suggest that a _hard_ rule (ie nobody can override it) would 
>    also be that the problem causes an oops, a hang, or a real security
>    problem that somebody can come up with an exploit for (ie no "there
>    could be a two-instruction race" crap. Only "there is a race, and
>    here's how you exploit it"). The exploit wouldn't need to be full code 
>    that gets root, but an explanation of it, at least.

Yeah.
> 
>  - a vetting process. You'd have ten people, and five of them would have 
>    to sign off on the patch, and even a single veto would shoot it down. 

Way overkill, if the maintainer can be trusted to either understand or 
pass the vetting to someone who does, more eyes increase the probability 
if someone rejecting a valid patch because they didn't understand it.
> 
>    Again, this is really to protect the sucker, and make it possible to
>    work: I don't think this can work with a creative person (everybody
>    else calls me "flaky", and I much prefer that "creative" word, it sounds
>    so much better), which I personally believe means that we don't _want_
>    people like Alan, Andrea, Andrew etc etc that have historically maintained
>    their own trees that sometimes have tried to do something like this.

I doubt he feels the need, paperwork for the sake of paperwork...
> 
>  - Finally: this tree never has any history past the "last release". When
>    a new kernel comes, the tree is frozen, and never to be touched again.

Which bouncds the effort to maintain a stable tree.

> Does this mean that some patches would never go into this tree? Yes. It
> would mean that patches that some people might feel very _strongly_ are
> good patches would never ever show up in this tree, but on the other hand,
> I can see this tree being useful regardless, and I think the lack of
> flexibility in this case is actually the whole _point_ of the tree. The 
> lack of flexibility is the very thing that makes this be the kind of base 
> that anybody else can then hang their own patches on top of. There should 
> never be a situation where "I'd like that tree, but I think xxxx was done 
> wrong".

As must be to be stable.
> 
> Might something like this make people happier? (I wrote "happy" rather
> than "happier" at first, but let's face it, people are better at whining
> than they are at being happy ;)

I think this is just what's needed, and it addresses both the delay in 
getting new features in as well as delay in getting fixes in a stable 
kernel.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: RFD: Kernel release numbering

[Jes Sorensen]

>>>>> "Greg" == Greg KH <greg@kroah.com> writes:

Greg> On Thu, Mar 03, 2005 at 02:52:21AM -0500, Jeff Garzik wrote:
>> Users have been clamoring for a stable release branch in any case,
>> as you see from comments about Alan's -ac and an LKML user's -as
>> kernels.

Greg> Sure they've been asking for it, but I think they really don't
Greg> know what it entails.  Look at all of the "non-stable" type
Greg> patches in the -ac and as tree.  There's a lot of stuff in
Greg> there.  It's a slippery slope down when trying to say, "I'm only
Greg> going to accept bug fixes."

Greg> Bug fixes for what?  Kernel api changes that fix bugs?  That's
Greg> pretty big.  Some driver fixes, but not others?  Driver fixes
Greg> that are in the middle of bigger, subsystem reworks as a series
Greg> of patches?  All of this currently happens today in the main
Greg> tree in a semi-cohesive manner.  To try to split it out is a
Greg> very difficult task.

Greg> So, while I like the _idea_ of the 2.6.x.y type releases, having
Greg> those releases contain anything but a handful of patches will
Greg> quickly get quite messy.

Greg,

Wouldn't this actually happen automatically simply by Linus switching
to being a lot more picky about whats accepted into an even release. I
agree that if it becomes too formal it could probably turn into an
unmaintainable mess. However, by simply making it a golden rule, then
developers can just continue pushing their patches and the people
above can just shift things to -mm that aren't deemed suitable for the
even release.

I think this would work quite well.

Cheers,
Jes

Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 03:28:22AM -0500, Jes Sorensen wrote:
> 
> Greg> So, while I like the _idea_ of the 2.6.x.y type releases, having
> Greg> those releases contain anything but a handful of patches will
> Greg> quickly get quite messy.
> 
> Wouldn't this actually happen automatically simply by Linus switching
> to being a lot more picky about whats accepted into an even release. I
> agree that if it becomes too formal it could probably turn into an
> unmaintainable mess. However, by simply making it a golden rule, then
> developers can just continue pushing their patches and the people
> above can just shift things to -mm that aren't deemed suitable for the
> even release.
> 
> I think this would work quite well.

Sure, but the point about people not testing the odd release would still
stand.  As it is today, we've been pretty good about only allowing
bugfixes into the later -rc releases.  But I know I start queuing
"bigger" fixes at that point in time, allowing them to get more testing
in -mm release, and generally trying to be conserative.  

And sometimes, people really want those "big" fixes, and they switch to
using the bk-usb patchset, or the bk-scsi patchset.  That happens a lot
for when distros work to stabilize their release kernels.  But that is
quite different from trying to do that for a 2.6.x.y release.

thanks,

greg k-h

Re: RFD: Kernel release numbering

[Dave Jones]

On Thu, Mar 03, 2005 at 12:53:53AM -0800, Greg KH wrote:

 > And sometimes, people really want those "big" fixes, and they switch to
 > using the bk-usb patchset, or the bk-scsi patchset.  That happens a lot
 > for when distros work to stabilize their release kernels.

For those that have no intention of staying close to mainline maybe.
The fact is that before a bitkeeper tree (or any other SCM tree) gets
merged with mainline, its subject to change. Sometimes completely dramatic
'throw it all away and start again' changes.  I know this because I've done it,
I know you've done it with pci/usb trees, and various other folks have
done it with their trees.

Pulling whole random subsystem bk snapshots into a vendor tree without
significant review of all contained changesets is the path to madness
unless you're prepared to maintain the resulting mess forever.

		Dave

Re: RFD: Kernel release numbering

[Barry K. Nathan]

On Thu, Mar 03, 2005 at 02:52:21AM -0500, Jeff Garzik wrote:
> even/odd means that certain releases (even ones) are more magical than 
> others.  That's weird, since users aren't used to that sort of thing in 
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> any other project.

Actually, we are:

Red Hat Linux 7.2:            not magical
Red Hat Enterprise Linux 2.1:     magical
Red Hat Linux 7.3:            not magical
Red Hat Linux 8.0:            not magical
Red Hat Linux 9:              not magical
Red Hat Enterprise Linux 3.0:     magical
Fedora Core 1:                not magical
Fedora Core 2:                not magical
Fedora Core 3:                not magical
Red Hat Enterprise Linux 4.0:     magical
Fedora Core 4:                not magical
...

Sure, Red Hat changes the name as well as the version number whenever they
make a magical release, but it's really the same concept.

-Barry K. Nathan <barryn@pobox.com>

Re: RFD: Kernel release numbering

[Arjan van de Ven]

On Thu, 2005-03-03 at 01:42 -0800, Barry K. Nathan wrote:
> On Thu, Mar 03, 2005 at 02:52:21AM -0500, Jeff Garzik wrote:
> > even/odd means that certain releases (even ones) are more magical than 
> > others.  That's weird, since users aren't used to that sort of thing in 
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > any other project.
> 
> Actually, we are:
> 
> Red Hat Linux 7.2:            not magical
> Red Hat Enterprise Linux 2.1:     magical
> Red Hat Linux 7.3:            not magical
> Red Hat Linux 8.0:            not magical
> Red Hat Linux 9:              not magical
> Red Hat Enterprise Linux 3.0:     magical
> Fedora Core 1:                not magical
> Fedora Core 2:                not magical
> Fedora Core 3:                not magical
> Red Hat Enterprise Linux 4.0:     magical
> Fedora Core 4:                not magical
> ...
> 
> Sure, Red Hat changes the name as well as the version number whenever they
> make a magical release, but it's really the same concept.

it's actually not. Red Hat Enterprise Linux is magical in that you get
actual support for it (in various degrees, depending on for what level
you want to pay). That is what sets it appart, not the actual bits.

Re: RFD: Kernel release numbering

[Barry K. Nathan]

On Thu, Mar 03, 2005 at 10:51:13AM +0100, Arjan van de Ven wrote:
> it's actually not. Red Hat Enterprise Linux is magical in that you get
> actual support for it (in various degrees, depending on for what level
> you want to pay). That is what sets it appart, not the actual bits.

IMO the bits are also magical, insofar as they get treated differently
(e.g. RHEL kernels always get backports whereas Fedora ones often get
updated altogether). If the bits weren't magical then I think people
would simply run Fedora Core instead of creating RHEL rebuild projects.

-Barry K. Nathan <barryn@pobox.com>

Re: RFD: Kernel release numbering

[Neil Brown]

On Wednesday March 2, davem@davemloft.net wrote:
> On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> > If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is 
> > preferable to even/odd.
> 
> All of these arguments are circular.  If people think that even/odd
> will devalue odd releases, guess what 2.6.x.y will do?  By that line
> of reasoning nobody will test 2.6.x just the same as they aren't
> testing 2.6.x-rc* right now.

I think there is a qualitative difference.
2.6.x is the end of a line that 2.6.x-rc* leads up to.  There is a
clear end.  "I will test when it gets to the end".

2.6.x.y doesn't.  If the releases are quick (daily if there is
anything to release) then there is no clear end to the list, just a
beginning.  There may never be a 2.6.x.1 for some values of x, so
people won't be able to wait for the .1 or the .2 release.  They will
have to just take what is available when they want to upgrade.

If we want to stop people from waiting for a final release before they
test, we need to make sure there isn't a (recognisable in advance)
final release.

NeilBrown

Re: RFD: Kernel release numbering

[David Lang]

On Thu, 3 Mar 2005, Neil Brown wrote:

> On Wednesday March 2, davem@davemloft.net wrote:
>> On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <jgarzik@pobox.com> wrote:
>>
>>> If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is
>>> preferable to even/odd.
>>
>> All of these arguments are circular.  If people think that even/odd
>> will devalue odd releases, guess what 2.6.x.y will do?  By that line
>> of reasoning nobody will test 2.6.x just the same as they aren't
>> testing 2.6.x-rc* right now.
>
> I think there is a qualitative difference.
> 2.6.x is the end of a line that 2.6.x-rc* leads up to.  There is a
> clear end.  "I will test when it gets to the end".
>
> 2.6.x.y doesn't.  If the releases are quick (daily if there is
> anything to release) then there is no clear end to the list, just a
> beginning.  There may never be a 2.6.x.1 for some values of x, so
> people won't be able to wait for the .1 or the .2 release.  They will
> have to just take what is available when they want to upgrade.

as one of the users since the mid 2.0 series. I really think this is the 
best approach.

with any 'stable' kernel series I have always had to wait at least a few 
days from the release to allow people to report brown-bag problems, and 
then I've needed to test it on my particular hardware to make sure there 
are no driver gotcha's that happen to bite my configuration, then I can 
deploy (either immediatly if it's a security issue, or after load testing 
if it's not)

the 2.6.odd/even won't change this at all

the 2.6.x.y will leave me needing to do the same thing for each new x, but 
any new .y releases that take place should be able to follow a more rapid 
path as they will probably have _very_ few changes in them (i.e. no driver 
updates that aren't significant bugfixes). and the ability to do more then 
one .y release if nessasary without confusing people is definantly an 
advantage over the odd/even approach

> If we want to stop people from waiting for a final release before they
> test, we need to make sure there isn't a (recognisable in advance)
> final release.

good point

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: RFD: Kernel release numbering

[Chris Friesen]

Jeff Garzik wrote:
> If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is 
> preferable to even/odd.
> 
> Just create a 2.6.X repo at each release.  For bug fixes to 2.6.X, 
> commit to this repo, then pull into linux-2.6.  For everything else, 
> pull straight into linux-2.6.

For what it's worth, I'd like to add a vote in support of this.  I like 
the idea of bugfixes being applied to previous versions (until the next 
stable one comes out, say).

Chris

Re: RFD: Kernel release numbering

[Willy Tarreau]

100% agree with you, Jeff. That's what I wrote in another mail.
A real -rc should have only a handful of patches. And even more
importantly, the final release MUST be EXACTLY the lastest -rc,
without any new surprize.

Willy

On Wed, Mar 02, 2005 at 11:16:19PM -0500, Jeff Garzik wrote:
 
> The reasons -rcs are not as good as they could be is that they include 
> more than just bug fixes.  Users are discouraged from testing because 
> they must scan LKML, or guess, which -rc that Linus/Andrew started 
> getting serious about "bugfixes only."
> 
> With the -pre/-rc scheme, it's clear to users.
> 
> With the even/odd scheme, you just devalue releases.  Previously, all 
> releases were worthy of testing and use.  Now, half of them aren't.
> 
> 	Jeff
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: RFD: Kernel release numbering

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> The reasons -rcs are not as good as they could be is that they include 
>  more than just bug fixes.

I thought we'd been fairly good about that, actually.  The -rc1's always
come too early for me (I usually wait for all the bk merges to happen). 
But once we hit -rc2 people are good?  At least, I think I've only ever
seen one "ytf did you merge that now" email...


<hack, hack>

Here you go: http://www.zip.com.au/~akpm/linux/patches/stuff/khack.jpeg

That's number-of-lines-of-patch versus day, from the bk-commits list. 
There's definitely a pattern there ;)

(Raw data at
http://www.zip.com.au/~akpm/linux/patches/stuff/commits.data.gz for anyone
who is inclined to spend more that seven seconds with gnuplot...)

Re: RFD: Kernel release numbering

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.58.0503021932530.25732@ppc970.osdl.org> (at Wed, 2 Mar 2005 19:37:44 -0800 (PST)), Linus Torvalds <torvalds@osdl.org> says:

> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 
> Might. Maybe.

I believe people soon stop using 2.6.<odd> "release"s.

--yoshfuji

Re: RFD: Kernel release numbering

[Russell Miller]

On Wednesday 02 March 2005 19:37, Linus Torvalds wrote:

> That's the whole point here, at least to me. I want to have people test
> things out, but it doesn't matter how many -rc kernels I'd do, it just
> won't happen. It's not a "real release".
>
> In contrast, making it a real release, and making it clear that it's a
> release in its own right, might actually get people to use it.
>
> Might. Maybe.
>
Linus, I respect all of the work you have done on the Linux kernels over the 
years, and I have been an avid user of Linux almost since its inception (when 
I could get it to work with the hardware, at least in the early days ;-)  And 
the fact that my contributions to the kernel are almost nonexistent probbly 
means you won't pay attention to a word I say anyway :-)  that's alright, I'm 
going to say it and you can listen if you want.

My respect for your accomplishments is why it pains me a great deal to have to 
tell you that I think you're wrong.

I agree with the first part of your mail that I quoted above.  Indeed, the -rc 
releases are not a "real release", and therefore people aren't going to test 
it.

What you are missing is that if you use the method you have proposed. odd 
numberered kernels will stop being a "real release" as well to a great deal 
of users.

I don't think you will actually gain anything here except for just changing 
the kernel naming scheme yet *again*.  I certainly don't think you're going 
to solve the problem you are trying to solve.

The problem as stated is that people are not downloading and testing the test 
releases.

Your solution to that problem is to make test releases look like real releases 
and maybe people will test them anyway.

The solution should be to find a way to encourage people to download and test 
the test releases.  Perhaps a "bug bounty" of some kind (it doesn't have to 
be money), or something similar, may prove to be a better motivator than 
trying to trick the userbase.  It's not going to work.  If you take the 
motivational approach, then it won't matter what you name the test releases, 
people will test them anyway.

Several ideas right off the top of my head:
- a "bug bounty" as I mentioned above.
- a volunteer army of people, similar to the "kernel janitors", whose job is 
to do QA for the kernel.

--Russell

-- 

Russell Miller - rmiller@duskglow.com - Agoura, CA

Re: RFD: Kernel release numbering

[Thomas Molina]

On Wed, 2 Mar 2005, Russell Miller wrote:

> On Wednesday 02 March 2005 19:37, Linus Torvalds wrote:
>
>> That's the whole point here, at least to me. I want to have people test
>> things out, but it doesn't matter how many -rc kernels I'd do, it just
>> won't happen. It's not a "real release".
>>
>> In contrast, making it a real release, and making it clear that it's a
>> release in its own right, might actually get people to use it.

> I agree with the first part of your mail that I quoted above.  Indeed, the -rc
> releases are not a "real release", and therefore people aren't going to test
> it.

> What you are missing is that if you use the method you have proposed. odd
> numberered kernels will stop being a "real release" as well to a great deal
> of users.

>
> The problem as stated is that people are not downloading and testing the test
> releases.

Define people. Some won't download a thing, they will take whatever the 
distros feed them. Some will download and test the latest patchset 
frequently, especially if someone asks. Some are interested only in a 
particular subsystem or feature.

> Your solution to that problem is to make test releases look like real releases
> and maybe people will test them anyway.

I believe the solution is slowly working its way out.  Previously there 
were only two stark choices, either you could be stable, safe, and boring, 
or you could use the development series and things could break horribly. I 
believe having a place where things could be tried out, such as the -mm 
kernels, was a great idea.

IMHO the 2.5 development series was long enough to be painful almost to 
the point of being counterproductive.  I think part of the problem with 
development series in general is/was a lack of focus. If the announced 
goal of the 2.5 series had been confined to changing module loading and 
latency/scheduling issues at the beginning, it would have been a lot 
shorter, and better.

I would like to see an even/odd stable/development cycle where the 
development cycle is limited to two or three major ideas and APIs don't 
change in stable cycles. New features not likely to cause breakage or new 
driver support could be targeted for the -mm kernels.

RE: RFD: Kernel release numbering

[Hua Zhong]

> And the reason it does _not_ work is that all the people we 
> want testing sure as _hell_ won't be testing -rc versions.

At least they still test "real" releases..

So instead of making sure rc is really "release-candidate", we want to trick
people to test -pre as "real release", soon people will realize it and just
stop testing even real releases. The trick won't last. What other names will
we try then? Seriously, this is silly and the focus is wrong, and will
accomplish nothing but confusing people one more time.

Let's start by making rc really "release-candidate", not something with
last-minute unpredictable random changes. Why should I test rc when I know
the final release will be much different anyway? What is worse is that we
actually _complain_ about the fact that people do not take rc seriously,
while the release management doesn't take it seriously itself.

Hua

Re: RFD: Kernel release numbering

[Barry K. Nathan]

On Wed, Mar 02, 2005 at 07:37:44PM -0800, Linus Torvalds wrote:
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
[snip]
> > 2.6.x-pre: bugfixes and features
> > 2.6.x-rc: bugfixes only
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.

Maybe that's because you redefined "rc" to mean "ridiculous count"?
People would rather test a release candidate than a ridiculous count. ;)

> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".
> 
> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 
> Might. Maybe.

Am I the only person here who doesn't see it as "either/or"? ISTM that
"odd/even" and the "2.4 approach" are orthogonal issues.

What about something like the following? (It probably needs tweaks but
it might be worth considering.)

2.6.odd-alpha1: Equivalent to 2.6.x-rc1.
...
2.6.odd-alphaA: Equivalent to 2.6.x-rcA. (A is a constant. Linus gets to
                set it, perhaps before relesing alpha1. Perhaps A=1 or
                A=2 could be tried for the 2.6.13 cycle. Setting it to
                an arbitrary value should free Linus's brain for other
                matters.)
2.6.odd-beta1:  Equivalent to 2.6.x-rc(A+1).
...
2.6.odd-betaX:  Equivalent to the last 2.6.x-rc in the current scheme.
2.6.odd-rc1:    Equivalent to 2.6.x *RELEASE* now.
...
2.6.odd:        *Identical* to last 2.6.odd-rc. Not a single patch of
                difference, except for the version number! If you
                committed anything since 2.6.odd-rcX, then either (a)
                you need to make a 2.6.odd-rc(X+1), or (b) you committed
                something that should have waited for the next 2.6.odd.
2.6.even-beta1: Skipping -alpha because we're only going for bugfixes
                in even, right? (*Please* listen to davej and don't
                treat drivers differently than core code. If you must
                include major driver updates, then don't skip -alpha.)
...
2.6.even-rc1:   This is when you think you're completely done with
                2.6.even and you think it's time to upload the final
                release.
...
2.6.even:       This is the last 2.6.even-rc, with no changes. (Same -rc
                rules as for 2.6.odd-rc.)
(...cycle repeats...)

For an approximation of the so-called "2.4 approach", let A=0 and
s/beta/pre/g. Perhaps the alpha/beta distinction won't *really* mean
anything, but it might have a subliminal effect on everyone. :) Anyway,
if the alpha/beta distinction is overengineering, it's easily removed
(see the beginning of this paragraph).

Whether with alpha/beta or just plain pre, this seems more robust to me
than the other suggestions so far.

-Barry K. Nathan <barryn@pobox.com>

Re: RFD: Kernel release numbering

[Rene Herman]

Linus Torvalds wrote:

>>2.6.x-pre: bugfixes and features
>>2.6.x-rc: bugfixes only
> 
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.

Speaking, presumably, as one of those people you are talking about, no, 
that is not correct.

Between 2.6.6-rc3 and 2.6.6, you merged an IDE patch that made my disk 
complain loudly and at the time I was fairly annoyed by that. I had been 
testing all the -rc's but then wondered what the point had been. Things 
could break anytime anyways so it seemed I might as well test whenever I 
personally felt like it rather than on anyone else's schedule, which is 
exactly what I did for a while.

Up to this point, I really only grab an -rc if I'm not doing anything 
interesting otherwise.

And this is just because your -rc's aren't -rc's. Yes, in a sense it's 
all just naming and I've been telling others that complained about it as 
much, but in the sense that I'm not testing as many -rc's as you would 
apparently like me to, it is more substantial after all.

Your even/odd point releases will not work. In no time at all the same 
people that now avoid -rc will then avoid odd releases, and they are the 
same people that will avoid the -pre releases. They are _not_ the exact 
same group of people that will be avoiding a real -rc as well though. I 
for instance would be likely to test every -rc you release, on the 
promise that if the thing works out it's final.

Doing -pre and real -rc will get you more testers for -rc. Whether or 
not it's enough remains to be seen, but it seems like something you 
could test out for a few months without much problem.

Add in the fourth level .k releases for real problematic bugs found 
after release as you did with 2.6.8.1, and I believe things should work.

Rene.

Re: RFD: Kernel release numbering

[Jeff Garzik]

Rene Herman wrote:
> Doing -pre and real -rc will get you more testers for -rc. Whether or 

> Add in the fourth level .k releases for real problematic bugs found 
> after release as you did with 2.6.8.1, and I believe things should work.

Precisely.

	Jeff

Re: RFD: Kernel release numbering

[Rene Herman]

Jeff Garzik wrote:

> Rene Herman wrote:
> 
>> Doing -pre and real -rc will get you more testers for -rc. Whether or 
> 
>> Add in the fourth level .k releases for real problematic bugs found 
>> after release as you did with 2.6.8.1, and I believe things should work.
> 
> Precisely.

I assume that one of the main problems with doing -pre is that actually 
doing a real -rc isn't much fun -- I can certainly understand that 
sitting around twiddling your thumbs by decree every few weeks is not a 
good model.

You commented on the .k 4th level releases being an actual branch, BK 
wise. To not let the forced thumb-twiddling -rc period be a problem, 
this branch could happen at -rc1, after which Linus is again free to go 
merge up stuff into mainline for the next one, if he wants to.

That's to say, I propose Linus doesn't change _anything_ other than 
renaming his -rc's -pre's, and his final -rc1 (well, and making it a 
branch if -final isn't a branch now, sorry, not a clue).

The -rc branch then just sits there, and if nothing turns up that needs 
an -rc2, it gets released as final, and possibly onto .1, .2 and so on 
if useful or need be.

Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and 
possibly beyond may not be something Linus wants to do. The -rc branch 
would by definition see _no_ activity other than the really needed so I 
don't believe it would be much of a burden time-wise, but it is in fact 
not unlike what Alan is already doing with -ac. So, if Linus doesn't 
want that job, Alan may? Or someone else?

Summarising:

- Linus:

	1) rename 2.6.N-rcX to 2.6.N-preX
	2) when you'd now release, branch off, release as -rc1
	3) go on with 2.6.(N+1)-pre1

- Linus, Alan, or whoever else wants the job:

	1) release -rc{2,3,...} only if needed.
	2) release 2.6.N
	3) do a 2.6.N.{1,2,...} only if needed.

Is this sane? The advantage is, real -pre's and -rc's which will get 
more people onboard testing -rc, and hopefully without annoying Linus 
with real no-changing -rc's. How many more, enough or not, remains to be 
  seen but certainly more.

Rene.

Re: RFD: Kernel release numbering

[John Alvord]

On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
<rene.herman@keyaccess.nl> wrote:

>Jeff Garzik wrote:
>
>> Rene Herman wrote:
>> 
>>> Doing -pre and real -rc will get you more testers for -rc. Whether or 
>> 
>>> Add in the fourth level .k releases for real problematic bugs found 
>>> after release as you did with 2.6.8.1, and I believe things should work.
>> 
>> Precisely.
>
>I assume that one of the main problems with doing -pre is that actually 
>doing a real -rc isn't much fun -- I can certainly understand that 
>sitting around twiddling your thumbs by decree every few weeks is not a 
>good model.
>
>You commented on the .k 4th level releases being an actual branch, BK 
>wise. To not let the forced thumb-twiddling -rc period be a problem, 
>this branch could happen at -rc1, after which Linus is again free to go 
>merge up stuff into mainline for the next one, if he wants to.
>
>That's to say, I propose Linus doesn't change _anything_ other than 
>renaming his -rc's -pre's, and his final -rc1 (well, and making it a 
>branch if -final isn't a branch now, sorry, not a clue).
>
>The -rc branch then just sits there, and if nothing turns up that needs 
>an -rc2, it gets released as final, and possibly onto .1, .2 and so on 
>if useful or need be.
>
>Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and 
>possibly beyond may not be something Linus wants to do. The -rc branch 
>would by definition see _no_ activity other than the really needed so I 
>don't believe it would be much of a burden time-wise, but it is in fact 
>not unlike what Alan is already doing with -ac. So, if Linus doesn't 
>want that job, Alan may? Or someone else?
>
>Summarising:
>
>- Linus:
>
>	1) rename 2.6.N-rcX to 2.6.N-preX
>	2) when you'd now release, branch off, release as -rc1
>	3) go on with 2.6.(N+1)-pre1
>
>- Linus, Alan, or whoever else wants the job:
>
>	1) release -rc{2,3,...} only if needed.
>	2) release 2.6.N
>	3) do a 2.6.N.{1,2,...} only if needed.
>
>Is this sane? The advantage is, real -pre's and -rc's which will get 
>more people onboard testing -rc, and hopefully without annoying Linus 
>with real no-changing -rc's. How many more, enough or not, remains to be 
>  seen but certainly more.

One way to handle the transition into bug-fix only  would be to turn
the tree over to the $stability crew at that moment. They would have
the job of nursing it to stability under the given ground rules.

john alvord

Re: RFD: Kernel release numbering

[Rene Herman]

John Alvord wrote:

> One way to handle the transition into bug-fix only  would be to turn
> the tree over to the $stability crew at that moment. They would have
> the job of nursing it to stability under the given ground rules.

Yes. However, the discussion is now over due to the .1 work which solves 
a different problem than was intended, which was getting more people to 
test kernels before they become 2.6.N final. It's going to take another 
few months again now for people to notice that, but oh well. Personally, 
I don't have a problem anyway. I think 2.6 is great ...

Rene.

Re: RFD: Kernel release numbering

[Anton Altaparmakov]

On Wed, 2 Mar 2005, Linus Torvalds wrote:
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> > 
> > If we want a calming period, we need to do development like 2.4.x is 
> > done today.  It's sane, understandable and it works.
> 
> No. It's insane, and the only reason it works is that 2.4.x is a totally
> different animal. Namely it doesn't have the kind of active development AT
> ALL any more. It _only_ has the "even" number kind of things, and quite 
> frankly, even those are a lot less than 2.6.x has.
> 
> > 2.6.x-pre: bugfixes and features
> > 2.6.x-rc: bugfixes only
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.
> 
> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".
> 
> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 
> Might. Maybe.

I agree with you.  And I think it definitely would.  A lot of people just 
go to ftp.kernel.org and get the latest full release (heck a lot of 
compile your own kernel scripts I have seen do that).  They never read 
LKML or related lists, they just try the latest released kernel.  You 
would catch that whole group of people by turning -rc into 2.6.ODD.

And not to forget companies where senior management will refuse to run -rc 
because its a beta and beta is not good enough for company use.

Its the same as with companies refusing to run 0.x software.  In the end 
the software developers usually end up doing a 1.x release just _so_ it 
gets run by those companies.

I think the .EVEN and .ODD proposal would work a lot better than -rc ever 
would/could.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: RFD: Kernel release numbering

[Jeff Garzik]

Anton Altaparmakov wrote:
> I think the .EVEN and .ODD proposal would work a lot better than -rc ever 
> would/could.

...until people find out the "secret" that .ODD is really beta.  Then we 
are back where we started.

	Jeff

Re: RFD: Kernel release numbering

[Anton Altaparmakov]

On Thu, 3 Mar 2005, Jeff Garzik wrote:
> Anton Altaparmakov wrote:
> > I think the .EVEN and .ODD proposal would work a lot better than -rc ever
> > would/could.
> 
> ...until people find out the "secret" that .ODD is really beta.  Then we are
> back where we started.

Ah, but you are assuming people think logically and they don't.  "2.6.ODD 
doesn't say beta so it can't be beta, right?"  I think this directly 
translates to the actually happening "0.x is not 1.x so it can't be 
usable, right?"  Both statements are crap but the second is real world and 
the first by analogy could be real world.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: RFD: Kernel release numbering

[David S. Miller]

On Thu, 3 Mar 2005 11:48:39 +0000 (GMT)
Anton Altaparmakov <aia21@cam.ac.uk> wrote:

> On Thu, 3 Mar 2005, Jeff Garzik wrote:
> > Anton Altaparmakov wrote:
> > > I think the .EVEN and .ODD proposal would work a lot better than -rc ever
> > > would/could.
> > 
> > ...until people find out the "secret" that .ODD is really beta.  Then we are
> > back where we started.
> 
> Ah, but you are assuming people think logically and they don't.

Right, this discussion is about human behavior.  And unless someone
here is a PhD in human behavioral studies, none of us can really
say anything coherent about what will really happen.

But that's ok, because we can "try it out" and see what happens.

Re: RFD: Kernel release numbering

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 3176 bytes --]

On Wed, 2005-03-02 at 19:37 -0800, Linus Torvalds wrote:
> 
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> > 
> > If we want a calming period, we need to do development like 2.4.x is 
> > done today.  It's sane, understandable and it works.
> 
> No. It's insane, and the only reason it works is that 2.4.x is a totally
> different animal. Namely it doesn't have the kind of active development AT
> ALL any more. It _only_ has the "even" number kind of things, and quite 
> frankly, even those are a lot less than 2.6.x has.
> 
> > 2.6.x-pre: bugfixes and features
> > 2.6.x-rc: bugfixes only
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.
> 
> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".
> 
> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 

See, the point that you are missing, is that the lack of testing is not
because of it being a -rc or -shouldworkprettydandy or whatever, but the
_stigma_ attached to 2.6 based -rc releases.  (Same reason why -mm is
not the most popular kernel around for those more conservative users.)

The first few -rc's was tested by the more conservative users, but then
things broken on them, and they went "what the hell?  Is this a -rc?",
and got the currently standard "sorry for your issues, but 2.6 -rc's
*might* be release ready or it might be a accident ready to happen.
Please check LKML for when Linus says to slow down" reply.  And how many
of your more conservative users will start to read LKML for that?

So now you are basically sitting with a situation where -rc's really do
not get the coverage they should, and 'stable' 2.6.x versions are really
not that stable, with lots of excuses being thrown around - its the
distro's job to make a stable kernel - comes to mind.  And you know what
- your conservative users (which this horkage is all about) actually
heard that via a friend/whoever that reads LKML.  The outcome? - many of
them probably do not even test 2.6.x kernels anymore, but wait for the
distro, or try -ac/-ck kernels until they get an issue there (the sound
issue with fedora that was mentioned comes to mind).

So if you ask me, the only visible effect that your new scheme will
have, is that maybe the first few 2.6.odd releases will be tested by
some of the conservative users still testing 'stable' kernel.org
kernels, but then the 'stigma' will just shift, and they will totally
rely on distro kernels or wait for patch sets that are known more stable
(dunno - ck/ac?). And thus making kernel.org kernels even more flaky.

Solution?  I cannot really comment here, as I do not know the effort to
queue and maintain lots of kernel patches for some time.  The -pre/-rc
scheme might work though from a user perspective if you can get the
stigma attached to 2.6 -rc's removed.  But that will take some time ...


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFD: Kernel release numbering

[Jochen Striepe]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

    Hi,

On 03 Mar 2005, Martin Schlemmer wrote:
[Why don't the rc's get the testing they need?]
> The first few -rc's was tested by the more conservative users, but then
> things broken on them, and they went "what the hell?  Is this a -rc?",
> and got the currently standard "sorry for your issues, but 2.6 -rc's
> *might* be release ready or it might be a accident ready to happen.
> Please check LKML for when Linus says to slow down" reply.  And how many
> of your more conservative users will start to read LKML for that?
> 
> So now you are basically sitting with a situation where -rc's really do
> not get the coverage they should, and 'stable' 2.6.x versions are really
> not that stable, with lots of excuses being thrown around - its the
> distro's job to make a stable kernel - comes to mind.  And you know what
> - your conservative users (which this horkage is all about) actually
> heard that via a friend/whoever that reads LKML.  The outcome? - many of
> them probably do not even test 2.6.x kernels anymore, but wait for the
> distro, or try -ac/-ck kernels until they get an issue there (the sound
> issue with fedora that was mentioned comes to mind).

Or they go back to 2.4 kernels. I agree 100% -- this is exactly what I
see when I look around over here.

Many thanks for finding the right words for what I had in mind!


Greetings,

Jochen.
-- 
Technology is a word that describes something that doesn't work yet.
                                -- Douglas Adams

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

Re: RFD: Kernel release numbering

[Ed Tomlinson]

On Wednesday 02 March 2005 22:37, Linus Torvalds wrote:
> 
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> > 
> > If we want a calming period, we need to do development like 2.4.x is 
> > done today.  It's sane, understandable and it works.
> 
> No. It's insane, and the only reason it works is that 2.4.x is a totally
> different animal. Namely it doesn't have the kind of active development AT
> ALL any more. It _only_ has the "even" number kind of things, and quite 
> frankly, even those are a lot less than 2.6.x has.
> 
> > 2.6.x-pre: bugfixes and features
> > 2.6.x-rc: bugfixes only
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.
> 
> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".
> 
> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 

It seems to me that the problem is not the numbering scheme.  We _will_
experience the same issues no mater what scheme we use...  The way I see
it is that we need a way to tell how much testing a given release has had.
I would suggest an opt outable scheme that records boot (via an email 
for instance) and asks for comments after a day or two.  With this sort of 
method we would _know_ just how much testing is done.  We eventually 
could start to relate the amount of testing to just how stable the kernel 
will be.

Comments
Ed Tomlinson

Re: RFD: Kernel release numbering

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> said:
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
> > If we want a calming period, we need to do development like 2.4.x is 
> > done today.  It's sane, understandable and it works.

> No. It's insane, and the only reason it works is that 2.4.x is a totally
> different animal. Namely it doesn't have the kind of active development AT
> ALL any more. It _only_ has the "even" number kind of things, and quite 
> frankly, even those are a lot less than 2.6.x has.
> 
> > 2.6.x-pre: bugfixes and features
> > 2.6.x-rc: bugfixes only
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.
> 
> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".
> 
> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 
> Might. Maybe.

Then do away with -preX -rcY -bkZ altogether... just release 2.6.W. Faster
release cycle, much higher chance that "the next release" fixes brokenness
fast. The whole (or most of it) odd/even thinking went out the window with
the new development model.

[I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
 the kind of tester you are looking for... haven't seen any of the
 showstopper bugs everybody is talking about, or I'd have screamed.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: RFD: Kernel release numbering

[Linus Torvalds]

On Thu, 3 Mar 2005, Horst von Brand wrote:
> 
> [I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
>  the kind of tester you are looking for... haven't seen any of the
>  showstopper bugs everybody is talking about, or I'd have screamed.]

Yeah, I wish everybody was like that. Sadly, it seems to be pretty rare to
have people do weekly builds, much less daily. Daily builds is the holy
grail for me, if just a small percentage of people did that, we'd be
really well off.. Right not it's not even a "percentage", it's a very much
self-selected small group of people, usually with what ends up actually
being fairly similar high-end PC hardware.

Now, I haven't actually gotten any complaints about 2.6.11 (apart from 
"gcc4 still has problems" with fairly trivial solutions), so maybe the 
whole cycle really worked out well this time, and I happened to choose a 
really bad time to bring up this discussion. Or maybe this discussion 
scared away people, and I just need to give it another week or two ;)

		Linus

Re: RFD: Kernel release numbering - an orthogonal solution

[David Greaves]

Linus Torvalds wrote:

>On Thu, 3 Mar 2005, Horst von Brand wrote:
>  
>
>>[I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
>> the kind of tester you are looking for... haven't seen any of the
>> showstopper bugs everybody is talking about, or I'd have screamed.]
>>    
>>
>
>Yeah, I wish everybody was like that. Sadly, it seems to be pretty rare to
>have people do weekly builds, much less daily. Daily builds is the holy
>grail for me, if just a small percentage of people did that, we'd be
>really well off.. Right not it's not even a "percentage", it's a very much
>self-selected small group of people, usually with what ends up actually
>being fairly similar high-end PC hardware.
>
>Now, I haven't actually gotten any complaints about 2.6.11 (apart from 
>"gcc4 still has problems" with fairly trivial solutions), so maybe the 
>whole cycle really worked out well this time, and I happened to choose a 
>really bad time to bring up this discussion. Or maybe this discussion 
>scared away people, and I just need to give it another week or two ;)
>
>		Linus
>  
>
I suspect you don't mean 'everybody'.
So who do you mean?

Why isn't there some advice on www.kernel.org that says:

  Do you use the Linux kernel?
  _You_ can make it better!!
  Here's how you can help...

and goes on to tell people how, depending on their familiarity and 
risk-aversion/linux-love ratio, they can install -mm kernels or -ck ones 
or -rc ones or -pre ones...

and it explains clearly what the intent and promises around each one are

and it explains the risks (probably in terms of likelihood of losing 
their digital photos!)

and it tells them how to subscribe to linux-kernel-announce

So they don't have to monitor lkml to know about them.


Maybe people like Horst could publicise the way in which they 
automatically download and deploy kernels.
I certainly wouldn't mind rebooting my desktop once a week to try a 
current kernel.

David

Re: RFD: Kernel release numbering

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> said:
> On Thu, 3 Mar 2005, Horst von Brand wrote:
> > [I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
> >  the kind of tester you are looking for... haven't seen any of the
> >  showstopper bugs everybody is talking about, or I'd have screamed.]

> Yeah, I wish everybody was like that. Sadly, it seems to be pretty rare to
> have people do weekly builds, much less daily. Daily builds is the holy
> grail for me, if just a small percentage of people did that, we'd be
> really well off.. Right not it's not even a "percentage", it's a very much
> self-selected small group of people, usually with what ends up actually
> being fairly similar high-end PC hardware.

I also fool around (not daily, but often) with a SPARC64. Ironing out some
trouble with that beast before screaming.

> Now, I haven't actually gotten any complaints about 2.6.11 (apart from 
> "gcc4 still has problems" with fairly trivial solutions), so maybe the 
> whole cycle really worked out well this time, and I happened to choose a 
> really bad time to bring up this discussion. Or maybe this discussion 
> scared away people, and I just need to give it another week or two ;)

Haven't looked at gcc4 recently (crashed on boot when I tried it). Worth
another round...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: RFD: Kernel release numbering

[Andrew Morton]

Linus Torvalds <torvalds@osdl.org> wrote:
>
> Now, I haven't actually gotten any complaints about 2.6.11 (apart from 
> "gcc4 still has problems" with fairly trivial solutions)

There have been quite a few.  Mainly driver stuff again:

Subject: Re: [BUG] 2.4.27 - 2.4.29 tar: /dev/nst0: Warning: Cannot seek: Illegal seekg
Subject: PCMCIA breaks suspend-to-(disk|ram) with 2.6.11
Subject:  2.6.11: iostat values broken ?
Subject: 2.6.11: suspending laptop makes system randomly unstable
Subject: [Bugme-new] [Bug 4281] New: ALPS Touchpad Tap-to-Click Broken
Subject: [Bugme-new] [Bug 4282] New: ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver
Subject: [Bugme-new] [Bug 4283] New: weird messages after normal kernel messages with enabled netconsole
Subject: 2.6.11 (stable and -rc) ACPI breaks USB


The biggest problem is the new ACPI-based i8042 probing on Dells.  I'm
kicking myself over that because we *knew* the damn thing was busted, and
people kept on having to add i8042.noacpi=1.  We now have a three-line
work-around-it-until-we-fix-it-for-real patch.

Re: RFD: Kernel release numbering

[Lee Revell]

On Thu, 2005-03-03 at 15:28 -0800, Andrew Morton wrote:
> Subject: [Bugme-new] [Bug 4282] New: ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver

Um... this one is highly suspect.  Myself and others have been doing a
lot of work on this driver lately, and have unloaded and reloaded it
hundreds and hundreds of times, and no one on the ALSA lists ever
reported this problem.  If this was real I really think we would have
heard of it a month ago.  The bug reporter did not even provide a
backtrace.

Lee 

Re: RFD: Kernel release numbering

[Jan Rychter]

>>>>> "Andrew" == Andrew Morton <akpm@osdl.org> writes:
 Andrew> Linus Torvalds <torvalds@osdl.org> wrote:
 >>
 >> Now, I haven't actually gotten any complaints about 2.6.11 (apart
 >> from "gcc4 still has problems" with fairly trivial solutions)

 Andrew> There have been quite a few.  Mainly driver stuff again:
[...]
 Andrew> The biggest problem is the new ACPI-based i8042 probing on
 Andrew> Dells.  I'm kicking myself over that because we *knew* the damn
 Andrew> thing was busted, and people kept on having to add
 Andrew> i8042.noacpi=1.  We now have a three-line
 Andrew> work-around-it-until-we-fix-it-for-real patch.

FWIW, this "minor regression" also occurs on other laptops, such as my
Sharp Mebius.

--J.

Re: RFD: Kernel release numbering

[Jeff Garzik]

I also note that part of the problem that motivates the even/odd thing 
is a tacit acknowledgement that people only _really_ test the official 
releases.

Which IMHO backs up my opinion that we simply need more frequent releases.

Part of this is a scalability problem.  Linux probably has more changes 
flowing into it than any other OS kernel on the planet.  We must deal 
with an ever-increasing number of changesets in a way that produces a 
usable kernel for our users.

	Jeff

Re: RFD: Kernel release numbering

[Ben Greear]

Jeff Garzik wrote:
> I also note that part of the problem that motivates the even/odd thing 
> is a tacit acknowledgement that people only _really_ test the official 
> releases.
> 
> Which IMHO backs up my opinion that we simply need more frequent releases.

That doesn't really help in my opinion.  We need the comfort of knowing
that if we do find a bug, then soon we will have a release that will fix
this bug, with a *very* high probability of not changing anything else
significantly, or adding new regressions.  The current wait between
the official releases is too long to wait for a bug fix, but it is also likely
that other regressions have slipped in due to the large churn in the code.

If you simply release faster, without doing bug-fix only releases, then
I think we'll continue to see regressions.

I think the 2.6.X.y release scheme could work, as others have mentioned.


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: RFD: Kernel release numbering

[David S. Miller]

On Wed, 02 Mar 2005 21:32:23 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> I also note that part of the problem that motivates the even/odd thing 
> is a tacit acknowledgement that people only _really_ test the official 
> releases.
> 
> Which IMHO backs up my opinion that we simply need more frequent releases.

This more frequent release idea will basically mimmick what the
even/odd idea will do, except that even/odd will have specific
engineering goals.  Development vs. pure bug fixing.

There are changes that simply have to sit for weeks if not months
in order for all the problems to be weeded out.  I think something
like the 4-level pagetable stuff is the best example.  And yes it
has to occur in Linus's tree so what precious few people do test
his live tree try out the new code.

Re: RFD: Kernel release numbering

[Thomas Graf]

* David S. Miller 2005-03-02 20:05
> On Wed, 02 Mar 2005 21:32:23 -0500
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> > I also note that part of the problem that motivates the even/odd thing 
> > is a tacit acknowledgement that people only _really_ test the official 
> > releases.
> > 
> > Which IMHO backs up my opinion that we simply need more frequent releases.
> 
> This more frequent release idea will basically mimmick what the
> even/odd idea will do, except that even/odd will have specific
> engineering goals.  Development vs. pure bug fixing.

Agreed, more frequent releases, even/odd, and 2.6.x.y all get down to
the same idea being making it easier for the end-user to test it and
thus achieving releases with less regressions.

I don't see any difference between 2.6.x.y and even/odd regarding
the process just after a stable release. The 2.6.x.y clearly has
the advantage that all those small nasty bugfixes such as missing
exports, typos and all the other one-liners can be brought to the end
user more easly in the middle of a development cycle. The even/odd
idea cleary has the advantage of a clear statement regarding what will
be the final release candidate. So let's combine both ideas and
get the advantages of both.

I think it is completely unimportant how to call it, be it .odd,
.even-test, .even-final-rc, 2.6.x.0 or whathever. The most important
part is to communicate this to the end-user. A well formed release
diagram on kernel.org would do just fine.

Basically it gets down to this:

 + > start of development cycle
 |            |<--+
 |            v   |
 |           rcX -+
 |            |
 |            v
 |         final rc
 |            | (Only fixes here)
 |            v
 +----- stable release -----> fixes branch---+
                         ^                   |
                         +-------------------+

It's already like this right now except that the final rc isn't
marked as such and a branch for stable release fixes (including
only the very imporant fixes) is missing.  The situation for the
maintainers wouldn't change a bit.

Applied to combined even/odd and 2.6.x.y it would be:

    2.6.12 -> 2.6.13-rcX -> 2.6.13 -> 2.6.14 -> 2.6.15-rcX
                                        |
                                        v
                                     2.6.14.y

My personal preference would be to suffix the final odd release with
-test just to more clearly mark it but that's a very minor cosmetic thing.

I'm not sure wehther the test release thing will increase the number
of testers but it's sure worth a try. A real advantage would be that
everyone interested in a smooth migration to the next stable release
can give the test release a try and will see eventual regressions
fixed before the final stable release with a very low risk of new
regressions.

Re: RFD: Kernel release numbering

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Wed, 02 Mar 2005 21:32:23 EST, Jeff Garzik said:
> I also note that part of the problem that motivates the even/odd thing 
> is a tacit acknowledgement that people only _really_ test the official 
> releases.
> 
> Which IMHO backs up my opinion that we simply need more frequent releases.

Or more testers of things other than <whatever we call stable this week>
(which is where I see the *real* problem as being).

It doesn't matter *what* we call the "testing" releases.  They aren't getting
tested enough.  I've posted a fair number of "the latest -mm broke FOO" notes -
but assuming that "the first guy to hit it" is randomly distributed across all
the -mm users, there really can't be a whole lot of others doing it, as my
number seems to come up waaay too often if there's a large pool of testers...

Either that, or I really *am* the most bleeding-edge loon in my time zone.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: RFD: Kernel release numbering

[Nick Piggin]

Andrew Morton wrote:

> Jeff Garzik <jgarzik@pobox.com> wrote:
>
>> IMO too confusing.
>>
>
> 2.6.even: bugfixes only
> 2.6.odd: bugfixes and features.
>
> That doesn't even confuse me!
>

I actually second Matt's request; -RCs à la 2.4.

Then your above becomes:
2.6.x-rc: bugfixes only
2.6.x-pre: bugfixes and features

And then that doesn't confuse end users either.

Not to mention that if we adopt a strict release candidate release style
(ie. last -rc is renamed to release), then you get to move some of the
burden of testing to the end user. Hopefully that will encourage more
people to test -rcs rather than "tricking" them into doing the testing.

And if we really make an effort to only do the first -rc with the
expectation that it will be the *only* one, then that will be a pretty
good incentive to test.

Nick

RE: RFD: Kernel release numbering

[Hua Zhong]

> I actually second Matt's request; -RCs à la 2.4.
> 
> Then your above becomes:
> 2.6.x-rc: bugfixes only
> 2.6.x-pre: bugfixes and features
> 
> And then that doesn't confuse end users either.

I'll jump in and third this. It looks the "honest" way. I know Linus is
always talking about "open source keeps people honest". Don't play game with
the naming. :-)

Hua

Re: RFD: Kernel release numbering

[Russell Miller]

On Wednesday 02 March 2005 17:23, Nick Piggin wrote:

> Then your above becomes:
> 2.6.x-rc: bugfixes only
> 2.6.x-pre: bugfixes and features
>
> And then that doesn't confuse end users either.
>
Speaking as an "ordinary" end user (there's nothing ordinary about me) I think 
the idea of even/odd releases is silly.  This accomplishes the same goals, 
and is less confusing all told.

Linus's plan will work well for about...  two releases, then people will wise 
up and stop testing the odd releases.  I know that's what I'll probably end 
up doing.

--Russell

-- 

Russell Miller - rmiller@duskglow.com - Agoura, CA

Re: RFD: Kernel release numbering

[Matt Mackall]

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> 
> This is an idea that has been brewing for some time: Andrew has mentioned
> it a couple of times, I've talked to some people about it, and today Davem
> sent a suggestion along similar lines to me for 2.6.12.
> 
> Namely that we could adopt the even/odd numbering scheme that we used to 
> do on a minor number basis, and instead of dropping it entirely like we 
> did, we could have just moved it to the release number, as an indication 
> of what was the intent of the release.

One last plea for the 2.4 scheme:

 a) all the crazy stuff goes in 2.6.x-preN, which ends up being
    equivalent to 2.6.<odd> and friends in your scheme
 b) bugfixes only in 2.6.x-rcN, which ends up being equivalent to
    2.6.<even>-* in your scheme.
 c) 2.6.x is always 2.6.x-rc<last> with just a version number change[1]

This has some nice features:

 - alternates as rapidly as you want between stable and development
 - no brown paper bag bugs sneaking in between -rc<last> and 2.6.x 
 - 2.6.* is suitable for all users, 2.6.*-rc* is suitable for almost
   all users
 - it's already in use for 2.4 and people are happy with it

I _really_ don't want to explain to people that they don't want to use
2.6.13 because it's an odd number but that 2.4.31 is just fine (and so
is 2.6.9). Nor do I want to teach my ketchup tool the difference
between 2.6-stable and 2.6-unstable.

> The problem with major development trees like 2.4.x vs 2.5.x was that the 
> release cycles were too long, and that people hated the back- and 
> forward-porting. That said, it did serve a purpose - people kind of knew 
> where they stood, even though we always ended up having to have big 
> changes in the stable tree too, just to keep up with a changing landscape.

I think naming the interim releases -pre/-rc has done this admirably
for 2.4.

--
Mathematics is the supreme nostalgia of our time.

Re: RFD: Kernel release numbering

[David Greaves]

Matt Mackall wrote:

>On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
>  
>
>>This is an idea that has been brewing for some time: Andrew has mentioned
>>it a couple of times, I've talked to some people about it, and today Davem
>>sent a suggestion along similar lines to me for 2.6.12.
>>
>>Namely that we could adopt the even/odd numbering scheme that we used to 
>>do on a minor number basis, and instead of dropping it entirely like we 
>>did, we could have just moved it to the release number, as an indication 
>>of what was the intent of the release.
>>    
>>
>
>One last plea for the 2.4 scheme:
>
> a) all the crazy stuff goes in 2.6.x-preN, which ends up being
>    equivalent to 2.6.<odd> and friends in your scheme
> b) bugfixes only in 2.6.x-rcN, which ends up being equivalent to
>    2.6.<even>-* in your scheme.
> c) 2.6.x is always 2.6.x-rc<last> with just a version number change[1]
>
>This has some nice features:
>
> - alternates as rapidly as you want between stable and development
> - no brown paper bag bugs sneaking in between -rc<last> and 2.6.x 
> - 2.6.* is suitable for all users, 2.6.*-rc* is suitable for almost
>   all users
> - it's already in use for 2.4 and people are happy with it
>
>  
>

I understand that :)
(and if 2.6.y+1-preX appeared before 2.6.y then that wouldn't be too 
confusing)
(neither would 2.6.y.1 as an 'oops' in the human sense)

--Joe User.

Who's scared to risk his personally valuable data on a 
2.6.x-pre<anything> - but will install, lets see, hmm, -rc2 or above :)
(I suppose the more paranoid I get, the higher the watermark I set on -rcX)

(I'm lying since I'm running a -mm on my server but that's only because 
I helped track down an XFS/nfsd bug!)

Re: RFD: Kernel release numbering

[Tim Bird]

Matt Mackall wrote:
> One last plea for the 2.4 scheme:
> 
> I think naming the interim releases -pre/-rc has done this admirably
> for 2.4.

I agree.  This makes more sense to me than some implicit understanding
about the parity of the revision.

rc is easy to understand, and '-pre' is easy to understand
once you recognize it means 'beta'.

I've been bothered in the 2.6 series that rc ("release candidate"?)
tags were applied to kernels that were clearly NOT release candidates.


=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: Kernel release numbering

[Richard Purdie]

Linus Torvalds:
> Namely that we could adopt the even/odd numbering scheme that we used
> to do on a minor number basis, and instead of dropping it entirely like
> we did, we could have just moved it to the release number, as an 
> indication
> of what was the intent of the release.

How about taking the idea a bit further and have two active versions. Eg: 
now 2.6.11 is out, new changes go into a 2.6.13 series. Any changes to make 
2.6.11 (more :) stable go into a 2.6.12 series which is 
stability/security/whatever improvements rather than devel work.

This way you can shorten the length of the time the odd series spends in -rc 
and can spend more time accepting patches rather than having long periods 
where developers queue them. Distributors are encouraged to use the even 
numbers including the even -rc versions and to give feedback as to what 
stability/whatever patches need adding to the even series to keep them 
happy.

Just an idea...

Regards,

Richard

Re: RFD: Kernel release numbering

[Neil Brown]

If I understand you correctly, what you are effectively saying is that
people don't test the -rc releases enough, so you are going to start
giving these releases a more formal name: 2.6.ODD.
That will encourage more people to test them, so that when you do a
real release (now called 2.6.EVEN instead of 2.6.X), it will be more
stable.

I don't buy this.  You won't fool anyone.  People will just start
using the .EVEN releases and you won't get any more testing than you
currently do.

A different approach would be to not release a 'stable' kernel at all,
but rather release 'fixup' patches.
i.e. you release 2.6.X as a 'testing' kernel and then start work on
2.6.X+1.
When a patch comes along that fixes a *real*problem* in 2.6.X, you add
that to a list of addenda for 2.6.X.  People who run 2.6.X can monitor
that list, applying patches that might be relevant to them.
You keep the addenda for 2.6.X going until 2.6.X+2 is released.

This way there is no clear distinction between "stable" and "testing"
kernels.  There is, instead, gradual transition.  People who want to
be cautious can decide to use
   A testing kernel that has been out for at least 2 weeks - plus addenda
as their definition of 'stable'.  Others might prefer
   A testing kernel that has been out for at least 6 weeks - plus relevant addenda
as their definition.

People who don't want to think, can pay a distributor to choose a
suitable definition of 'stable'.

This way, you are giving your army of beta-testers clear information
on their level of risk, and allowing them to choose precisely  what
level they want.  Giving people information and choice is always good
when you want them to help you.


That is the 'testing' side of the equation.  The other side is the
'developing' side.

I have been (naively?) assuming that Andrew Morton is the 2.6 kernel
maintainer, because that is what was announced, and I haven't seen any
announcement to alter that.  
So I have been sending all my patches to Andrew to go in the -mm tree,
with the understanding that he would forward them on to Linus as
appropriate, and this has been working quite well.
I feel free to send any patch to Andrew at any time, but try to make
it clear which ones should be considered "work-in-progress", which
should be considered 'important-bug-fix' and which sit in between.

I had (even more naively?) been assuming that this is what other
developers were doing.  i.e. that this was the approved approach.

But more recently I have discovered that quite a few key developers
develop against Linus' kernel and submit patches directly to him,
apparently bypassing Andrew.  This leads to them holding back patches
when a release is approaching, rather than sending them straight to
Andrew for -mm and wider testing.  This doesn't sound like a good
thing.


Now, I know our movement is all about freedom (and openness), and you
don't want to force developers into any behaviour patterns that aren't
essential, but I think it would be nice if there was some uniform
perspective on how patches should flow so that we all understood what
each other were doing.

My own preference would be:
  - all patches go to Andrew and appear in -mm promptly
  - Linus only gets patches from -mm
     - most patches are only passed to Linus after they have
       been in an -mm release for at least ....   1 week (?)
     - some patches go straight to Linus even before a -mm
       release if maintainer + Andrew + Linus review and agree
     - some patches stay in -mm for extended periods getting refined
       before making their way to Linus.
     - some patches get ditched from -mm and never make it to Linus.

Is this too restrictive?
Is it too much work for Andrew?
Is it too little work for Linus :-?


Whatever the final answer, the key is to give all your volunteer
supporters (both testers and developers) good information and good
choices (and don't try to deceive them).

NeilBrown

Re: RFD: Kernel release numbering

[Andrew Morton]

Neil Brown <neilb@cse.unsw.edu.au> wrote:
>
> But more recently I have discovered that quite a few key developers
> develop against Linus' kernel and submit patches directly to him,
> apparently bypassing Andrew.  This leads to them holding back patches
> when a release is approaching, rather than sending them straight to
> Andrew for -mm and wider testing.  This doesn't sound like a good
> thing.
> 

Only davem, AFAIK.  All the other trees get auto-sucked into -mm for
testing.  Generally the owners of those trees make the decision as to which
of their code has been sufficiently well-tested for a Linus merge, and when
that should happen.

> Now, I know our movement is all about freedom (and openness), and you
> don't want to force developers into any behaviour patterns that aren't
> essential, but I think it would be nice if there was some uniform
> perspective on how patches should flow so that we all understood what
> each other were doing.
> 
> My own preference would be:
>   - all patches go to Andrew and appear in -mm promptly
>   - Linus only gets patches from -mm
>      - most patches are only passed to Linus after they have
>        been in an -mm release for at least ....   1 week (?)
>      - some patches go straight to Linus even before a -mm
>        release if maintainer + Andrew + Linus review and agree
>      - some patches stay in -mm for extended periods getting refined
>        before making their way to Linus.
>      - some patches get ditched from -mm and never make it to Linus.

That's basically what happens now, except I don't physically send the
patches from those 32 bk trees to Linus.

Re: RFD: Kernel release numbering

[Neil Brown]

On Wednesday March 2, akpm@osdl.org wrote:
> 
> Only davem, AFAIK.  All the other trees get auto-sucked into -mm for
> testing. 

Ok, I got the feeling it was more wide spread than that, but I
apparently misread the signs (people mentioning that had 'patches
queued for Linus' and such).

>           Generally the owners of those trees make the decision as to which
> of their code has been sufficiently well-tested for a Linus merge, and when
> that should happen.

I wonder if there is a problem here.
Who is in a position to judge when a patch is ready to be merged?
I suspect that it would be hard for a developer to be objective about
the readiness of their own patches (I know all my patches are perfectly
ready the moment I create them, despite what experience tells me :-)

Assuming we have a 'stable', a 'testing' and a 'devel' series
(whatever actual numbering gets used for them(*)), then maybe it is ok
for a developer to judge if it is ready for 'testing', but it should
really have either some minimum time in 'testing' or independent
review before being allowed into 'stable'.

Are you and Linus able to handle the independent review load?
Should every developer/maintainer find someone to review any patches
that they think should 'jump the queue'.
(Would anyone like to review my nfs/raid patches for me?  I review
patches I get from others, but find it very hard to review my own
work.  Andrew does a good job, but does miss things sometimes). 

NeilBrown


(*) Options for naming:

Devel              Testing                 Stable
2.ODD.X            2.EVEN.X                2.EVEN.X-ac
2.6.X-mm           2.6.X-rc                2.6.X
2.6.X-mm           2.6.ODD                 2.6.EVEN
2.6.X-mm           2.6.X                   2.6.X + patch addenda <--- my preferred
2.6.X-pre          2.6.X-rc                2.6.X

It doesn't matter much what you call them, but I think the three-way
distinction is needed, and there needs to be a well-understood set of
rules for patches moving from one to the next.

NeilBrown

Re: RFD: Kernel release numbering

[Jeff Garzik]

Neil Brown wrote:
> On Wednesday March 2, akpm@osdl.org wrote:
> 
>>Only davem, AFAIK.  All the other trees get auto-sucked into -mm for
>>testing. 
> 
> 
> Ok, I got the feeling it was more wide spread than that, but I
> apparently misread the signs (people mentioning that had 'patches
> queued for Linus' and such).

I don't think you misread, necessarily.

Andrew auto-sucks trees, which is different from sprinkling Holy Penguin 
Pee on the trees.

	Jeff

Re: RFD: Kernel release numbering

[Andrew Morton]

Neil Brown <neilb@cse.unsw.edu.au> wrote:
>
> On Wednesday March 2, akpm@osdl.org wrote:
> > 
> > Only davem, AFAIK.  All the other trees get auto-sucked into -mm for
> > testing. 
> 
> Ok, I got the feeling it was more wide spread than that, but I
> apparently misread the signs (people mentioning that had 'patches
> queued for Linus' and such).

I'd like to get my sticky paws onto Dave's tree actually, but haven't got
around to hassling.  He doesn't buffer much, or for very long anwyay.

> >           Generally the owners of those trees make the decision as to which
> > of their code has been sufficiently well-tested for a Linus merge, and when
> > that should happen.
> 
> I wonder if there is a problem here.
> Who is in a position to judge when a patch is ready to be merged?
> I suspect that it would be hard for a developer to be objective about
> the readiness of their own patches (I know all my patches are perfectly
> ready the moment I create them, despite what experience tells me :-)

True.  But if someone tries a big push when we're after -rc1 it will get
extra attention.  Basically, nobody does that.

> Assuming we have a 'stable', a 'testing' and a 'devel' series
> (whatever actual numbering gets used for them(*)), then maybe it is ok
> for a developer to judge if it is ready for 'testing', but it should
> really have either some minimum time in 'testing' or independent
> review before being allowed into 'stable'.
> 
> Are you and Linus able to handle the independent review load?

No.  That's why I'm always spamming people and asking them to ack stuff.

I don't think Linus or I pay much attention to patches which come in via
-bk trees - if the owners of those trees break them, they get to fix them.

That does leave open the problem that people can merge crappy code which
happens to work.  That's what hch is for ;)

Really, to a large extent the kernel doesn't use the "dictator" model any
more.  It's more like the "various people have commit permissions" model,
only they don't actually autonomously do a physical commit.

> Should every developer/maintainer find someone to review any patches
> that they think should 'jump the queue'.

Queue-jumping is a pain, and we should only do it with good reason.

That being said, kernel development is remarkably decoupled, in that there
is rarely overlap between the various subsystems.  Otherwise I couldn't sit
on up to 900 patches all the time.  Sometimes there is overlap between the
32 bk trees, and I'll usually tell people so that it gets sorted out.

Reviewing is important, and it's a bit of a problem that patches can get
merged into the mainline tree via this particular path:

 developer
 -> subsystem maintainer (maybe cc'ed to obscure mailing list)
    -> Couple of weeks in -mm for testing
    -> Linus via bk pull

This bypasses the main review site: linux-kernel.  Because the people on
<obscure mailing list> may not have the motivation/skills/experience.  And
things do sneak through.  Greg usually cc's linux-kernel on stuff as he
sends it to Linus, which is good.  But it's a problem.

Good changelogging really helps the review process.  If the submitter can
skilfully tell the reviewer what the patch does, why and how then the
review process becomes largely a matter of checking that the patch does
what he meant it to do.  The _understanding_ process happens while you read
the changelog.  In an ideal world.


> (Would anyone like to review my nfs/raid patches for me?  I review
> patches I get from others, but find it very hard to review my own
> work.  Andrew does a good job, but does miss things sometimes). 

Yes, it's hard.  If one is lucky, it's "hey, that locking looks funny". 
And, usually, "your coding style is sucky".  But apart from that, one needs
to be pretty heavily involved in the particular area to comment usefully.

So I think your question should be rephrased as "would anyone else like to
become nfsd/raid developers".

workflow (was Re: RFD: Kernel release numbering)

[Jeff Garzik]

Other ideas <thinking out loud>...

I maintain my netdev-2.6 queue by creating a ton of "subject-specific" 
repositories locally,

> 8139cp/     bonding/  ieee80211/    mips/     sis900/    typhoon/
> 8139too/    e1000/    ixgb/         misc/     skge/      viro-iomap/
> 8139too-2/  ham/      janitor/      mv643xx/  sk_mca/    viro-iomap-orinoco/
> ALL/        ibmlana/  kill-iphase/  pcnet32/  smc91x/    viro-isa-ectomy/
> atmel/      ibmtr/    mii/          s2io/     sundance/  wifi/

and I pull all of these into a master repository netdev-2.6 (locally 
'ALL').  netdev-2.6, in turn, gets pulled into -mm when Andrew makes a 
new release.  When I am ready to push something upstream, I pull one or 
more repositories into my net-drivers-2.6 queue, which is essentially my 
"push to upstream" queue.

This scheme allows me to cherry-pick fixes and features.  If a critical 
fix comes along, it doesn't have to wait for the other less-critical 309 
changesets to go.


We could have a linus-pending-2.6 queue, managed by Linus, that 
functions in a similar manner to my netdev-2.6:

a) Have a monthly or weekly official release.  Could be automated, but 
probably not.

b) snapshots of linus-pending-2.6 function as a development tree, taking 
over some of the current -mm purpose...  -mm is just too massive and 
multi-purpose at this point

c) locally [or publicly?], Linus sorts patches and 'bk pulls' into 
specific repositories, as I do with netdev-2.6.  "sata", "sata-fixes", 
"net drivers", "net drivers - janitorial", etc. could be potential pull 
queues from me to Linus.

d) When features/fixes are ready to move from linus-pending-2.6 to 
linux-2.6 repository, Linus just does a pull+push locally.  Fixes would 
likely go immediately into linux-2.6, unless it needs staging in 
linus-pending-2.6 first.  Potentially destabilizing stuff stays longer 
in linus-pending-2.6.

Thus, Linus controls the patch flow (and stability/features) simply by 
choosing when to pull stuff from the on-going dev tree that he manages.

e) Andrew continues doing what he's been doing:  merging tons of 
patches, staging big features, etc.


So what does this accomplish, besides increasing the complexity of 
Linus's work?  What's the point?

1) Creates a structure to enable linux-2.6 to be the on-going stable 
tree, by creating an official on-going dev tree.

2) Release early, release often.  The proposal that started this thread 
does the opposite: it slows things down.

3) Makes it easier to manage the flow of changesets.

4) Takes pressure off -mm to be "everything under the sun."  Users are 
far more likely to test a tree that is blessed with Holy Penguin Pee, 
and builds on all architectures.  And this in turn gives -mm more freedom.

	Jeff, trying to think outside the box

RE: Kernel release numbering

[Massimo Cetra]

Linus Torvalds wrote:

> Namely that we could adopt the even/odd numbering scheme that 
> we used to do on a minor number basis, and instead of 
> dropping it entirely like we did, we could have just moved it 
> to the release number, as an indication of what was the 
> intent of the release.

> Comments?

This is surely a good idea because end users (not developers) like me would
have greater possibility not to occur in a regression with an even release.

The real solution to the problem of having a really stable kernel is, IMHO,
to have a wide base of testers.
Usually, following a new stable release announce, lots of bugs get out
because people starts using the new kernel, just because they didn't try any
of the previous -RC releases.

So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, i'll have a more
stable 2.6.16 ? 
Will users help testing an odd release to have a good even release ? Or will
they consider an even release as important as a -RC release ?

My thought is that the community should do some marketing on the actual
developing model to obtain a wider testing base, or, with the new proposed
model, let people know that their help is necessary to have a stable kernel
and they should download, compile and install odd releases.

Sincerely,
 
 Massimo Cetra

RE: Kernel release numbering

[Sven-Haegar Koch]

On Thu, 3 Mar 2005, Massimo Cetra wrote:

> Linus Torvalds wrote:
>
>> Namely that we could adopt the even/odd numbering scheme that
>> we used to do on a minor number basis, and instead of
>> dropping it entirely like we did, we could have just moved it
>> to the release number, as an indication of what was the
>> intent of the release.
>
>> Comments?
>
> This is surely a good idea because end users (not developers) like me would
> have greater possibility not to occur in a regression with an even release.

What I would like to see as an enduser is (dreaming):
 	kernel 2.6.x - last released

 	often released (every 1-2 weeks) kernel 2.6.x.z
 	containing just the answers to the often repeating
 	lkml questions which are answered with "use $this simple patch"

 	kernel 2.6.y-pre/rc/bk - development, working towards 2.6.y

in practice your proposed 2.6.even changes, but these continued until the 
next kernel is released, not stopped after 1-2 weeks with the worst fixes.
(a bit like the -as series, but with the "official blessing")

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: Kernel release numbering

[Ben Greear]

Massimo Cetra wrote:

> So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, i'll have a more
> stable 2.6.16 ? 
> Will users help testing an odd release to have a good even release ? Or will
> they consider an even release as important as a -RC release ?

I think it would be useful for folks to test the 2.6.ODD release because
the understanding is that 2.6.ODD+1 will be out soon, and we are pretty
sure there won't be any large changes in that transition.  Any out-side-the-tree
patches will probably apply to both of these w/out manual hacking,
which also makes testing easier.

I am less likely to test an ODD.pre-Z release because there is likely to be
a large pile coming after that, which means that even if pre-Z worked
fine, I still have to be very paranoid about the final release.

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Kernel release numbering

[Jochen Striepe]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

    Hi,

On 03 Mar 2005, Massimo Cetra wrote:
> So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, i'll have a more
> stable 2.6.16 ? 
> Will users help testing an odd release to have a good even release ? Or will
> they consider an even release as important as a -RC release ?

 From my experience this won't work (at least it won't work as inten-
ded). I see a tendency of people going away from Linux-2.6, going back
to Linux-2.4, or even going to one of the free BSD's. They go away
because they have the feeling they cannot rely any longer on the stabi-
lity of the 2.6 kernel branch (there are other issues, but this one is
common with most people I talked).

What you really need to avoid this (as far as I can see) is a stable
Kernel branch that does not give you a huge surprise every time you do
a kernel upgrade. Some mediocre statement like "this one might be quite
ok" is not enough -- you need to declare that 2.6.EVEN is *stable*, that
it is ready for production use. When people give it a test, fix the bugs
they find, and release anew without adding any other "improvements". This
way the user gets the least surprises when doing the next update -- and
that is what gets you more users on 2.6: the users will feel they can
*rely* on the stable releases.

At least that's how it looks here. And yes, I *know* it's harder to do
development when you're stuck with maintaining a stable branch. It's
your choice.


Greetings,

Jochen.
-- 
I worry about my child and the Internet all the time, even though she's too
young to have logged on yet.  Here's what I worry about.  I worry that 10 or
15 years from now, she will come to me and say "Daddy, where were you when
they took freedom of the press away from the Internet?"     -Mike Godwin

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

RE: Kernel release numbering

[Massimo Cetra]

Jochen Striepe wrote: 
> On 03 Mar 2005, Massimo Cetra wrote:
> > So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, 
> i'll have a 
> > more stable 2.6.16 ?
> > Will users help testing an odd release to have a good even 
> release ? 
> > Or will they consider an even release as important as a -RC 
> release ?
> 
>  From my experience this won't work (at least it won't work 
> as inten- ded). I see a tendency of people going away from 
> Linux-2.6, going back to Linux-2.4, or even going to one of 
> the free BSD's. They go away because they have the feeling 
> they cannot rely any longer on the stabi- lity of the 2.6 
> kernel branch (there are other issues, but this one is common 
> with most people I talked).

I agree.

I have no problem testing new releases on my laptop.
I could't care less if it hangs or explode.

But when I have to upgrade a wide set of servers, 400 Km away from my desk,
I would be really happy if everything goes just fine.

This is the reason why I have 2.4 on my production systems and 2.6 on my
laptop.

Usable does not means that it simply works.
It means it works like as charm as the previous releases and has no
regressions.

> What you really need to avoid this (as far as I can see) is a 
> stable Kernel branch that does not give you a huge surprise 
> every time you do a kernel upgrade. Some mediocre statement 
> like "this one might be quite ok" is not enough -- you need 
> to declare that 2.6.EVEN is *stable*, that it is ready for 
> production use. When people give it a test, fix the bugs they 
> find, and release anew without adding any other 
> "improvements". This way the user gets the least surprises 
> when doing the next update -- and that is what gets you more 
> users on 2.6: the users will feel they can
> *rely* on the stable releases.
> 
> At least that's how it looks here. And yes, I *know* it's 
> harder to do development when you're stuck with maintaining a 
> stable branch. It's your choice.

The kernel renumbering would probably have some benefits over development,
but will _not_ enlarge the testing base.

That I think is that an enlargement of the testers is needed and it would
provide more regression reports.

As a mantainer of other products (not related to kernel and not as important
and big as the kernel), I have noticed that many people dowload patches but
only a few percentage reports error...

So... My proposal is simply this:
- TELL THE MEDIA (tv, radio, papers, websites) that users have to test to
help developing the kernel testing RC versions.

- write a clear monkey-proof howto on how to report regressions and bugs
 (many people does not even know how to do it)

- write some scripts to package a report and send it (almost) automatically
 (many people does not have time to gather informations)

- write a small script to  report working configurations (lspci,lsmod and
similar, kernel version & patches)
 (this would be used to have known working configurations)

It needs work, of course. It's not simple.

But the problem is avoiding bugs and regressions to have the stablest
kernel.
To avoid bugs, you have to know them.
To know them you need reports.
To have reports, you need a wide range of testers.
To let testers report problems, you need them to understand how to do it.

Tricking users with bogus stable releases is not a solution.

(obviously it is _NOT_ from a developer point of view.)

Massimo Cetra

Re: RFD: Kernel release numbering

[Paul Jackson]

The key thing I look at is total cycle time, from any particular point
in the cycle, to when that same point comes around again.

In 2.4 and before, the cycle time was a long time, I hear tell. 
Perhaps, at some points, things were sufficiently chaotic that it
was difficult to discern any particular cycle time (FFT of releases
resembled pink noise ;?).

In 2.6.x since June 2004, the cycle time has been two months.  Cool.

My employer (SGI) has to push new features through the main Linux
kernel, and then through the Linux distributors we work with, such as
SuSE and Red Hat, before they reach our customers.  And we tend to live
on the leading edge, so depend on these features.

The longer the new feature cycle time in Linux, then the longer on the
average (depending on just how we line up) it takes us to get a feature
to our customers.

I really like the two month cycle we have now.  It's fast.

If your 2.6.<odd>, 2.6.<even> proposal extended that cycle time to four
months (two months <odd>, two months <even>), that would hurt.  Not the
end of Planet Earth, but still an owie.

The times you give, of a month or two for the <odd>, and a week or two
for the <even>, if taken literally, add up to roughly the same two
months, give or take a few weeks.  This is good.

But I've long since learned to take initial time estimates from
engineers (and from my wife, when we're getting ready to go out) with
a few grains of salt.

How serious are you about these time estimates?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401

Re: RFD: Kernel release numbering

[Ryan Anderson]

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> The problem with major development trees like 2.4.x vs 2.5.x was that the 
> release cycles were too long, and that people hated the back- and 
> forward-porting. That said, it did serve a purpose - people kind of knew 
> where they stood, even though we always ended up having to have big 
> changes in the stable tree too, just to keep up with a changing landscape.

How about this idea, instead:

At 2.6.12, make two parallel BitKeeper trees:

2.6 and 2.7

Push bugfixes into 2.6.

Push *everything* that's not a bugfix into 2.7.
"bk pull" the 2.6 tree into the 2.7 tree each day when you wake up.

A week later, release 2.6.12.1 from the 2.6 tree, then immediately bk
pull the 2.7 tree into the 2.6 tree.

Release 2.6.13-rc1 at about the same time, and again only take bugfixes
into the 2.6 tree.

In 3-7 weeks, after a few more -rc iterations with just bugfixes,
release 2.6.13.

This should keep the differences between the trees down to something
somewhat... sane, and, hopefully, keep the stable tree stable.

People working on big changes can do them against 2.6.x if they need
stability, and know that if they stay current with each 2.6.x release as
they work, they should have a controllable amount of pain for merges.

My thinking is simply that if you're going to use BitKeeper, you might
as well abuse it for all that it's worth.

-- 

Ryan Anderson
  sometimes Pug Majere

Re: RFD: Kernel release numbering

[Chris Wedgwood]

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:

>  - 2.6.<even>: even at all levels, aim for having had minimally intrusive
>    patches leading up to it (timeframe: a week or two)
>
> with the odd numbers going like:
>
>  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up
>    to it (timeframe: a month or two).
>  - 2.<odd>.x: aim for big changes that may destabilize the kernel for
>    several releases (timeframe: a year or two)

[...]

Why not change the "2.6 prefix" to 2.8, 3.0 (or whatever) if/when you
do go to a new naming scheme --- simply to make a clean break between
the new and the old.  Plus it will give the suckdork crowd[1] bigger
numbers to drivel on about.

That said it would be a large numerical leap without and real feature
changes so perhaps that will further add to confusion?

Sigh.



[1] Well, and the CGL and similar people.  "New CGL with improved
    version numbers and fewer calories!"

Re: RFD: Kernel release numbering

[Arjan van de Ven]

> 
> Comments?

the problem is that this doesn't tackle some of the fundamentals...

yes you have a step in between for extra stabilisation. However during
that phase, the buildup of patch backlogs will keep going on, and the
next "unstable" release is all the more so, because of all the enormous
backlogs. Result the stabilisation takes longer. Which means the buildup
next time is even bigger. And that may well be a cycle you can't get out
of. Oh and most people will just start skipping the odd releases as
well. Making this even worse.

An alternative would be to instead of doing the alternating scheme, do
higher frequency releases but with less new features per release. (like
we had in early 2.6 days). Say 3 weeks of devel, 3 weeks of -rc and then
release. Do it time driven so that stuff that gets found to be broken
during -rc gets punted back (to -mm or so) for trying in a later
release. (even when it was added before -rc; if the bug is found before
-rc starts it has a chance for a fix, if it's during -rc it means "back
out for next release"). This sounds harsh but as long as the "next
chance" isn't that far in the future (three weeks at most before it is
back) it shouldn't be a big deal. 

Re: RFD: Kernel release numbering

[Bernhard Schauer]

As far as I understand the numbering scheme, the 2.5 kernel leads to 2.6
series. 
Why not just reactivate the 2.5 kernel (Starting with i.e. 2.5.112 which
will lead to 2.6.12)?
There will be no change visible to end-users and developers - IMO - are
more flexible in any case. 

(I know I totally ignore some basic thoughts with that "idea".)

Re: RFD: Kernel release numbering

[Helge Hafting]

Linus Torvalds wrote:

>In other words, we'd have an increasing level of instability with an odd 
>release number, depending on how long-term the instability is.
>
> - 2.6.<even>: even at all levels, aim for having had minimally intrusive 
>   patches leading up to it (timeframe: a week or two)
>
>with the odd numbers going like:
>
> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
>   to it (timeframe: a month or two).
> - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
>   several releases (timeframe: a year or two)
> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>   the kernel to be a microkernel using a special message-passing version 
>   of Visual Basic. (timeframe: "we expect that he will be released from 
>   the mental institution in a decade or two").
>
>  
>
Fine with me - but I tend to run mm kernels anyway to get the "latest". :-)

Now, if this implies linux 3.0.0 won't ever happen, how about getting
rid of the major number?  It serves no purpose if not used at all. (I don't
consider the VB thing realistic . . .)

Or, if you want to keep the major number for consistency with earlier
kernels, consider:
2.<even>  minimally intrusive patches
2.<odd> big changes needing a month
<odd>.x big changes that destabilize over several releases
2.x.y takes the role 2.x.y.z has today.

Helge Hafting

Helge Hafting

Re: RFD: Kernel release numbering

[Barry K. Nathan]

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> So the suggestion on the table would be to go back to even/odd, but do it 
> at the "micro-level" of single releases, rather than make it a two- or 
> three-year release cycle.

[WARNING: At this point I have pulled an all-nighter, for reasons
unrelated to Linux. I may not be making sense anymore. This will
probably be my last post in this thread for today, or maybe even
forever.]

Is a 1:1 ratio necessarily the correct one? IOW, maybe alternatives like
the following should be considered (S = stable, ES = extra-stable, EES =
extra-extra-stable):

       | odd/even | ES every 5th | S, ES, EES, ...
---------------------------------------------------
2.6.11 | S        | S            | S
2.6.12 | ES       | S            | ES
2.6.13 | S        | S            | S (align for EES on divisible by 3)
2.6.14 | ES       | S            | ES
2.6.15 | S        | ES           | EES
2.6.16 | ES       | S            | S
2.6.17 | S        | S            | ES
2.6.18 | ES       | S            | EES
2.6.19 | S        | S            | S
2.6.20 | ES       | ES           | ES
2.6.21 | S        | S            | EES
2.6.22 | ES       | S            | S
...

e.g. if odd/even causes too many long releases or other problems like
that, then something like the middle column (every Nth release is
extra-stable, for N >= 3) could be tried.

-Barry K. Nathan <barryn@pobox.com>

Re: RFD: Kernel release numbering

[Paul Dickson]

On Wed, 2 Mar 2005 14:21:38 -0800 (PST), Linus Torvalds wrote:

> The reason I put a shorter timeframe on the "all-even" kernel is because I
> don't want developers to be too itchy and sitting on stuff for too long if
> they did something slightly bigger. In theory, the longer the better
> there, but in practice this release numbering is still nothing but a hint
> of the _intent_ of the developers - it's still not a guarantee of "we
> fixed all bugs", and anybody who expects that (and tries to avoid all odd 
> release entirely) is just setting himself up for not testing - and thus 
> bugs.
> 
> Comments?

You still haven't solved the problem of only a small group using the
development kernels.  Until a "stable" kernel is released, the majority
of kernel compilers will avoid any development kernel (even on this
mailing list!).

Two suggestions (one or both could be implemented):

How about appointing maintainers for 2.6.N kernels, whose responsibility
is apply stability and security patches for 3 months AND until 2.6.N+3 is
released.  So a series of 2.6.11.M kernels will appear until 2.6.14 and
2.6.11 is at least 3 months old.  This would given kernel developers
experience with such releases, but without the job being for the life of
the developer.

Also, add a list to the kernel.org web page about which kernels are
considered stable.  Listed stable kernels are those who have been
released for at least two weeks.

	-Paul

Re: RFD: Kernel release numbering

[Alan Cox]

On Mer, 2005-03-02 at 22:21, Linus Torvalds wrote:
>  - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up 
>    to it (timeframe: a month or two).
>  - 2.<odd>.x: aim for big changes that may destabilize the kernel for 
>    several releases (timeframe: a year or two)
>  - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
>    the kernel to be a microkernel using a special message-passing version 
>    of Visual Basic. (timeframe: "we expect that he will be released from 
>    the mental institution in a decade or two").

We still need 2.6.x.y updates on a more official footing and with more
than one person as the "2.6.x.y" maintainer. I think that is actually
more important.

The 2.6.<odd> thing is essentially irrelevant. You are just relabelling
pre
and rc to even and odd. It won't fool anyone into testing it more....

Re: RFD: Kernel release numbering

[Jeff Garzik]

On Thu, Mar 03, 2005 at 10:15:46PM +0000, Alan Cox wrote:
> We still need 2.6.x.y updates on a more official footing and with more
> than one person as the "2.6.x.y" maintainer. I think that is actually
> more important.

That appears to be the consensus conclusion we've arrived at.

	Jeff

Re: RFD: Kernel release numbering

[Andrea Arcangeli]

On Thu, Mar 03, 2005 at 05:32:03PM -0500, Jeff Garzik wrote:
> On Thu, Mar 03, 2005 at 10:15:46PM +0000, Alan Cox wrote:
> > We still need 2.6.x.y updates on a more official footing and with more
> > than one person as the "2.6.x.y" maintainer. I think that is actually
> > more important.
> 
> That appears to be the consensus conclusion we've arrived at.

FWIW I'm still unconvinced changing the 2.6.x naming scheme in any way
is needed to accomplish the goal of having more time to develop some
significant feature.

Another thing I'm unconvinced is that any numbering scheme could change
the amount of testing of the non-final stuff. The thing is that a lot of
users are just users, and they're not willing to test experimental
things, they've no time and no money to do that, they only need the
kernel running stable and fast. So I wouldn't even try to change the
release numbering if the object is to increase the testing userbase.

Comparing the number of people downloading the 2.6.11 compared to the
number of people downloading 2.6.11-rc5 is just like comparing apples to
oranges. We've to work with the oranges and we shouldn't expect
the apples to help with that. (this ignoring that lots of apples runs
the distro kernels anyways, I do too in my productive environments)

I don't see why we don't start with a very short 2.7.0/2.7.1/2.7.2
semi-stable cycle then after a few months we call it 2.8.0?  What's the
point of that 2.6 number, just to waste network bandwidth, disk space,
pixels and keypresses?

This way would be backwards compatible with the old numbering habits.

Perhaps one day we could even get a 3.0 kernel that way ;)

This still requires somebody taking care of a 2.6.12 if a security issue
showup, but 2.6.12 should not be developed any further since after a few
months 2.8.0 would be there already, so perhaps you can take care of the
security issues yourself without handing it off to a maintainer
dedicated to it.

This is very similar to what is being suggested except you want to
change the numbering scheme to do that, and that seems an unnecessary
complication to me.

The median number could go up to 255 without problems IIRC the limit is
256, like 2.200.0/1/2/3. So if Linus make a new release every week and 3
relases per stable/unstable cycle, we'll get 3.0.0 in another 14 years.

Still you can stack -pre/-rc on top of that.

So in short I don't really see the point of breaking the number scheme
to achieve your plan (whatever your plan is ;), 3 numbers + -pre/-rc
seems more than enough for whatever you're planning doing with the new 4th
number. You've just not to get emotional about 2.6/2.7 being magical and
unchangable, and to "unblock" them since now there seems to be need of
them for the first time (since 2.6 is getting mature but still we don't
want to slow down the development or wait years for the new features to
be usable and get stuck in heavy backports). You should just make clear
the semantics of 2.7 will not be the ones that 2.5 and 2.3 had.

I recall I made the example last year at KS that the 4th level ptes was
something that could open up 2.7, as Dave agreed that kind of stuff needs
a bit of time to settle, and 2.7 would have been ok for that, and a few
days ago you could have shipped a 2.8.0 instead of a 2.6.11! But at the
same time if a super security bug in the firewall code would showup
you'd be lined up to issue a 2.6.11 immediatly with only that bugfix in
it.

This will allow people to stay with the old rule, i.e. that if they use
the *.\..*[02468]\..* releases they're safe. No need to break this rule
established by decades to achieve your goal IMHO. Breaking rulings for
no good reason will only bring _more_confusion_ to the end user IMHO.

I've no idea if BK fits this, but (besides the fact I don't actually
care about that) it should pose you exactly same technical SCM troubles
that a fourth number would introduce, even ignoring the internal kernel
breakages with KERNEL_VERSION in include/linux/version.h.

Even with 2.6.8.1 I never got why it's called 2.6.8.1 and not 2.6.9,
what's the cost of a minor number, why to break the numbering? (even
ignoring that even 2.6.8.1 has an unstable VM that can underflow while
valuating the "min" value in alloc_pages due a NUMA patch, fixed by Nick
in 2.6.9-pre of course and is a more serious bug than what was fixed
between 2.6.8 and 2.6.8.1 IMHO ;)

Re: RFD: Kernel release numbering

[David Lang]

the 2.6.x.y numbering scheme has the huge advantage that nobody can ever 
know if there will be a 2.6.x.2 release (I think it's fairly safe to say 
that there will probably useually be a 2.6.x.1 release with _some_ fix in 
it) so people can't fall into the trap of 'waiting for the next release'

given the timeframe that bug reports come in I'd say 2.6.x.1 will probably 
come out 2-3 days after 2.6.x (although if people decide not to test 2.6.x 
there won't ever end up being a 2.6.x.1 becouse 2.6.x+1 will be out first 
:-)

avoiding any promises of if/when updates will be released (at least after 
the first one) combined with the fact that 2.6.x.y will be abandoned 
shortly after 2.6.x+1 is released will put a very definante cap on the 
amount of time that it's worth someone to wait in an attempt toget a 
'perfect' kernel

and if this lifetime is too short for enough people then more people will 
help maintain the .y releases and they can live a little longer (not too 
long, becouse they will very quickly devolve into backport kell)

with any odd/even release you are making a promise that you will produce 
the nect version in a reasonably timely manner so people can just wait for 
it instead.

David Lang



  On Fri, 4 Mar 2005, 
Andrea Arcangeli wrote:

> Date: Fri, 4 Mar 2005 00:41:30 +0100
> From: Andrea Arcangeli <andrea@suse.de>
> To: Jeff Garzik <jgarzik@pobox.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Linus Torvalds <torvalds@osdl.org>,
>     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: RFD: Kernel release numbering
> 
> On Thu, Mar 03, 2005 at 05:32:03PM -0500, Jeff Garzik wrote:
>> On Thu, Mar 03, 2005 at 10:15:46PM +0000, Alan Cox wrote:
>>> We still need 2.6.x.y updates on a more official footing and with more
>>> than one person as the "2.6.x.y" maintainer. I think that is actually
>>> more important.
>>
>> That appears to be the consensus conclusion we've arrived at.
>
> FWIW I'm still unconvinced changing the 2.6.x naming scheme in any way
> is needed to accomplish the goal of having more time to develop some
> significant feature.
>
> Another thing I'm unconvinced is that any numbering scheme could change
> the amount of testing of the non-final stuff. The thing is that a lot of
> users are just users, and they're not willing to test experimental
> things, they've no time and no money to do that, they only need the
> kernel running stable and fast. So I wouldn't even try to change the
> release numbering if the object is to increase the testing userbase.
>
> Comparing the number of people downloading the 2.6.11 compared to the
> number of people downloading 2.6.11-rc5 is just like comparing apples to
> oranges. We've to work with the oranges and we shouldn't expect
> the apples to help with that. (this ignoring that lots of apples runs
> the distro kernels anyways, I do too in my productive environments)
>
> I don't see why we don't start with a very short 2.7.0/2.7.1/2.7.2
> semi-stable cycle then after a few months we call it 2.8.0?  What's the
> point of that 2.6 number, just to waste network bandwidth, disk space,
> pixels and keypresses?
>
> This way would be backwards compatible with the old numbering habits.
>
> Perhaps one day we could even get a 3.0 kernel that way ;)
>
> This still requires somebody taking care of a 2.6.12 if a security issue
> showup, but 2.6.12 should not be developed any further since after a few
> months 2.8.0 would be there already, so perhaps you can take care of the
> security issues yourself without handing it off to a maintainer
> dedicated to it.
>
> This is very similar to what is being suggested except you want to
> change the numbering scheme to do that, and that seems an unnecessary
> complication to me.
>
> The median number could go up to 255 without problems IIRC the limit is
> 256, like 2.200.0/1/2/3. So if Linus make a new release every week and 3
> relases per stable/unstable cycle, we'll get 3.0.0 in another 14 years.
>
> Still you can stack -pre/-rc on top of that.
>
> So in short I don't really see the point of breaking the number scheme
> to achieve your plan (whatever your plan is ;), 3 numbers + -pre/-rc
> seems more than enough for whatever you're planning doing with the new 4th
> number. You've just not to get emotional about 2.6/2.7 being magical and
> unchangable, and to "unblock" them since now there seems to be need of
> them for the first time (since 2.6 is getting mature but still we don't
> want to slow down the development or wait years for the new features to
> be usable and get stuck in heavy backports). You should just make clear
> the semantics of 2.7 will not be the ones that 2.5 and 2.3 had.
>
> I recall I made the example last year at KS that the 4th level ptes was
> something that could open up 2.7, as Dave agreed that kind of stuff needs
> a bit of time to settle, and 2.7 would have been ok for that, and a few
> days ago you could have shipped a 2.8.0 instead of a 2.6.11! But at the
> same time if a super security bug in the firewall code would showup
> you'd be lined up to issue a 2.6.11 immediatly with only that bugfix in
> it.
>
> This will allow people to stay with the old rule, i.e. that if they use
> the *.\..*[02468]\..* releases they're safe. No need to break this rule
> established by decades to achieve your goal IMHO. Breaking rulings for
> no good reason will only bring _more_confusion_ to the end user IMHO.
>
> I've no idea if BK fits this, but (besides the fact I don't actually
> care about that) it should pose you exactly same technical SCM troubles
> that a fourth number would introduce, even ignoring the internal kernel
> breakages with KERNEL_VERSION in include/linux/version.h.
>
> Even with 2.6.8.1 I never got why it's called 2.6.8.1 and not 2.6.9,
> what's the cost of a minor number, why to break the numbering? (even
> ignoring that even 2.6.8.1 has an unstable VM that can underflow while
> valuating the "min" value in alloc_pages due a NUMA patch, fixed by Nick
> in 2.6.9-pre of course and is a more serious bug than what was fixed
> between 2.6.8 and 2.6.8.1 IMHO ;)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: RFD: Kernel release numbering

[Clemens Schwaighofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/2005 07:21 AM, Linus Torvalds wrote:

> Comments?

before you do this, we have to make -rc's real rc's. Seriously how can
it be that there is a diff between the last rc and the "vanilla"
release. Thats a no-goer in my opinion. Even if it is small things,
there is a chance that it breaks. If there patches that have to be
applied, because they are bugfixes, then make another rc before going live.

And odd/even sub number won't help here anyway. People who get the
kernel won't know it, there will be confusion, etc.

I would stick with the current scheme, I see no big advantage in a
special odd/even numbering. If there is a bugfix release, call it
X.Y.Z.1 like for 2.6.8, rest of the bugfixing can be found in -ac/-as
patchsets anyway.

The time of using vanilla kernels is long over. Nowadays its more like,
something, where you wait that a vendor gives you a kernel, or else you
will shot your own foot off ...

- --
[ Clemens Schwaighofer                      -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group                           ]
[                6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp        http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCJ+W4jBz/yQjBxz8RAgnoAKCKGVcIujulCLyk8p3ole80RhhcOwCgyHSM
tD2sZv+sCz7oG5MfokKh05c=
=lnqT
-----END PGP SIGNATURE-----

Re: RFD: Kernel release numbering

[Adam]

I decided to write the following proposal after getting a headache
trying to explain the Linux versioning scheme to a friend of mine.
Only then did I find that the powers that be are talking about the same
thing.  It's far from a complete “engineering standard” but it
makes sense to me.

Disclaimers: INAKD (I am not a kernel developer) and IANASA (I am not a
systems analyst)



<major>.<minor>.<patch>.<bugfix>

<major>	is incremented when user-space ABI is broken.

<minor>	is incremented when there has been a big change/rewrite to one
of the primary subsystems this would include times when for example the
default scheduler was changed or the memory management algorithms were
modifed.

<patch>	is incremented when a smaller change has been made to one of
the primary subsystems, module has been added or depreciated.  Modules
should only be depreciated not be removed from the tree entirely during
a <patch> release removal should be reserved for <minor> releases.
Although it may be tempting to roll fixes that haven't yet been
released in <bugfix> releases this should be avoided.

<bugfix>	is used and incremented as needed when fixing security
vulnerabilities and bugs that cause systems to oops, panic and other
nasty behavior.  Features and speedups should never added in a bugfix
release.


Andrew's -mm tree would still exist though I think it would make sense
if it were renamed to something like -dev or -exp (exp being short for
experimental) to better convey the purpose of the tree to newbie kernel
hackers and PHBs alike.  The policy for this tree would be much more
flexible as a development environment is required to be.  With a
designated development tree and more frequent <minor> release the
odd/even minors could be done away with.  Kernel developers, power
users and other such folk should be encouraged to run the latest
-dev/-exp releases where possible to test out current development
directions.

Although I have no experience with BK it seems to me that the it should
be possible to implement a work flow as described above in any SCM.

--adam

Re: RFD: Kernel release numbering

[Indrek Kruusa]

 > I'd love for the -mm tree to get more testing, but it doesn't.

So the question is how to hook up more "customers" for testing thing?

mm...maybe OSDL should provide special live mini-distro weekly, which 
will run entirely from 256 MB USB flashdrive :)
Lot of automated testing, lot of nice and colorful progressbars, graphs 
(it is ubelieveable how people love to watch how defragmentation goes) 
etc. and you are there :)

If the only question is to boot my computer from CD/flash (without 
touching my harddrive) and pushing at the end "I'm agree to send 
automatically collected results to OSDL" then you can count me as a 
tester :)


thanks,
Indrek

Re: RFD: Kernel release numbering

[szonyi calin]

--- Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
> 
> Certainly -mm can be the feature tree, but i've noticed that
> not that many 
> people run -mm aside from developers. Meaning that a fair
> number of bugs 
> seep into Linus' tree before they get attended to. It would
> even be more 
> effective if we could get more -mm user coverage. A Linus
> based odd number 
> might be closer to that if we hope on people unwittingly
> running them.

I used to run mm. I don't submit bug reports because i'm lazy
;-).
Now i don't run it because 2.6 doesn't look very usable and i
 don't want to test two development versions. Also sometimes is 
handy to have a stable version around when something goes wrong
(i.e. filesystem corruption after a crash or power failure).

I had my filesystem trashed with 2.6 so i'm more carefull now. 


--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: RFD: Kernel release numbering

[szonyi calin]

--- Jeff Garzik <jgarzik@pobox.com> wrote:
> Greg KH wrote:
> > On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds
> wrote:
> > 
> > 
> > But when pressed about the issue of speed of development,
> rate of
> > change, feature increase, driver updates, and so on, no one
> else has any
> > clue of what to do.  They respond with, "but only put
> bugfixes into a
> > stable release."  My comeback is explaining how we handle
> lots of
> > different types of bugfixes, by api changes, real fixes, and
> driver
> > updates for new hardware.  Sometimes these cause other bugs
> to happen,
> > or just get shaken out where they were previously hiding
> (acpi is a
> > great example of this issue.)  In the end, they usually fall
> back on
> > muttering, "well, I'm just glad that I'm not a kernel
> developer..." and
> > back away.
> 
> The pertinent question for a point release (2.6.X.Y) would
> simply be 
> "does a 2.6.11 user really need this fix?"
> 

no. If something is not working in 2.6.11 i will switch to 
2.6.10 ;-) and _maybe_ report  a bug

> 
> > Like I previously said, I think we're doing a great job. 
> The current
> > -mm staging area could use some more testers to help weed
> out the real
> > issues, and we could do "real" releases a bit faster than
> every 2 months
> > or so.  But other than that, we have adapted over the years
> to handle
> > this extremely high rate of change in a pretty sane manner.
> 
> I think Linus's "even/odd" proposal is an admission that 2.6.X
> releases 
> need some important fixes after it hits kernel.org.
> 
> Otherwise 2.6.X is simply a constantly indeterminent state.
> 

Let me tell you what i understood from this thread:
2.6.12 "almost stable"
2.6.13 devel (new drivers,fixes  and stuff -- may be broken)
2.6.14 (based on 2.6.13) tries to became stable again
2.6.15 also devel (see above)
2.6.16 (based on 2.6.15) also tries to became stable again

So we will _want_ to have a stable kernel (like 2.4 now) but 
this will never happen (see above) 

> We need to serve users, not just make life easier for kernel
> developers ;-)
> 

You said it. Hopefully you will make our life easier and we 
(as testers) will make your's.

> 	Jeff
> 



--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: RFD: Kernel release numbering

[Chris Friesen]

szonyi calin wrote:

> Let me tell you what i understood from this thread:
> 2.6.12 "almost stable"
> 2.6.13 devel (new drivers,fixes  and stuff -- may be broken)
> 2.6.14 (based on 2.6.13) tries to became stable again
> 2.6.15 also devel (see above)
> 2.6.16 (based on 2.6.15) also tries to became stable again
> 
> So we will _want_ to have a stable kernel (like 2.4 now) but 
> this will never happen (see above) 

No.  Linus' proposal was shouted down.

What is happening is that Linus will continue to release 2.6.x as usual, 
with no even/odd stuff.

Then a review committee will maintain 2.6.x.y (where y starts at 1 and 
increments).  This will contain obvious fixes against 2.6.x.  When Linus 
comes out with 2.6.x+1, then they will start a new stable tree 2.6.x+1.y.

Please see the thread entitled "[RFC] -stable, how it's going to work.", 
started by Greg KH for more information on the "stable" release process.

Chris

Re: RFD: Kernel release numbering

[szonyi calin]

--- Lee Revell <rlrevell@joe-job.com> wrote:
> On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote:
> >  --- Dave Jones <davej@redhat.com> a écrit : 
> > Taking into account that nobody responded on lkml nor
> > on alsa (the message was awaiting modderator aprouval 
> > on alsa-devel) i don't think i will send more bug reports 
> > to alsa. 
> 
> How long ago was this?  alsa-devel has been accepting messages
> from
> non-subscribers for at least 6 months.
> 

It's from 10th of september 2004
I managed to find it on the internet:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/0996.html

The same problem appears in 2.6.11
I'll repost the bug report asap

> Lee
> 
> 
> 

--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: RFD: Kernel release numbering

[viking]

Linus wrote (back on 4th March):
:The even/odd situation would have made for a situation that some people
:seem to be arguing for (more explicit calming-down period), but with the
:difference that I think the odd ones should definitely have been
:user-release quality already. But that one was apparently hated by so many
:people that it's not even worth trying.

:The fact is, there is no perfect way of doing things, and this discussion 
:has degenerated into nothing but whining. Which is kind of expected, but 
:let's hope that the only non-whining that came out of this (Greg  co's 
:trials with 2.6.x.y) ends up being worthwhile.

I'm sorry I didn't get to read this earlier. I apologise for stepping in here,
not being a core developer, however, this is what I tend to think about kernel
releases.

Even/odd at the next level down would confuse p.o.u like me. We kind of
grasped that 2.4 was okay to run (generally, anyone remember 2.4.12?) but a
walk with 2.5 was definitely taking your hard drive for a walk. When 2.6 came
along as the new devel kernel (as I perceived everyone saying) I got confused,
then decided to wait to see what happened. It ended up looking like I would
hawe perceived a true 2.6 tree to be - mostly stable, yet a few nice features
being added. The MAJOR difference for me was that there WASN'T a 2.7 feeding
nice stuff to the 2.6 tree - it was all going in directly. Nice.

The new 2.6.x.y has turned out to be an interesting change for me, being
previously used to 2.x.y. I'm guessing the reason for this is that Greg
decided to be a little more fine-grained with releases, so as to reduce
(somewhat) the major jump from 2.6.x to 2.6.x+1 for the developers, who
internally went through 2.6.x+1-rc[123...], and 2.6.x+1-pre[n].

Frankly, I wasn't seeing the major jump, and was thinking of it as perhaps a
few bugs found each time, maybe a couple of fixes, and by the time you'd gone
from 2.6.4 (for example) to 2.6.12, or maybe even 2.6.19, lots of new features
were added, and 98% of the bugs shaken out. So much for the view of a simple
desktop user.

I'm finding the finer granularity a little confusing, as I'm not sure if the
patches are cumulative (not the case in the past for patches on a Linus
kernel) or I just happen to hit a couple of weird patches. Going from 2.6.11.2
to .3, I was told I had seemingly applied one of the patches already, and it
was the same when going from .3 to .4 - not many failures, usually only one or
two.

I like 2.6.  I don't think any of my machines will ever go back to 2.4 (except
perhaps for my wife's machine, but that's another matter <grin>), I like using
it. 

And next time, I won't wait for 20 days before making a comment. Hopefully.

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|    flying-brick    | $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/     5.40      : I planted them carrots right here!!