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
Linus Torvalds <[email protected]> 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>.
__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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On 2005-03-02T14:21:38, Linus Torvalds <[email protected]> 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 <[email protected]>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
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
/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
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
Andrew Morton wrote:
> Linus Torvalds <[email protected]> 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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
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
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
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?
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.
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
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
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
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
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
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
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
Jeff Garzik <[email protected]> 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.
Andrew Morton wrote:
> Jeff Garzik <[email protected]> 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
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
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
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
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
On Wed, 02 Mar 2005 19:29:35 -0500
Jeff Garzik <[email protected]> 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 :-)
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
Neil Brown <[email protected]> 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.
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
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
In article <[email protected]> (at Wed, 2 Mar 2005 16:58:30 -0800), "David S. Miller" <[email protected]> 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
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
Dave Jones <[email protected]> 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?
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
On Wednesday March 2, [email protected] 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
Andrew Morton wrote:
> Jeff Garzik <[email protected]> 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
On Wed, 2 Mar 2005, David S. Miller wrote:
> On Wed, 02 Mar 2005 19:29:35 -0500
> Jeff Garzik <[email protected]> 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
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/)
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
> 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
On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:
> On 2005-03-02T14:21:38, Linus Torvalds <[email protected]> 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.
On Wed, Mar 02, 2005 at 05:20:49PM -0800, Andrew Morton wrote:
> Dave Jones <[email protected]> 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
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
On Wednesday March 2, [email protected] wrote:
> Dave Jones <[email protected]> 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
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 - [email protected] - Agoura, CA
On Wednesday 02 March 2005 19:58, David S. Miller wrote:
>On Wed, 02 Mar 2005 19:29:35 -0500
>
>Jeff Garzik <[email protected]> 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.
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 [email protected]
>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.
David S. Miller wrote:
> On Wed, 02 Mar 2005 19:29:35 -0500
> Jeff Garzik <[email protected]> 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
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
* Dave Jones ([email protected]) 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
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 <[email protected]> 1.650.933.1373, 1.925.600.0401
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
Neil Brown wrote:
> On Wednesday March 2, [email protected] 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
Neil Brown <[email protected]> wrote:
>
> On Wednesday March 2, [email protected] 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".
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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)
Gene Heskett <[email protected]> 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.
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
On Wednesday March 2, [email protected] 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
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
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
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
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
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
On Wed, 2 Mar 2005 14:21:38 -0800 (PST), Linus Torvalds
<[email protected]> 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
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
On Wed, 02 Mar 2005 22:40:57 -0500
Jeff Garzik <[email protected]> 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.
On Wed, 02 Mar 2005 21:32:23 -0500
Jeff Garzik <[email protected]> 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.
In article <[email protected]> (at Wed, 2 Mar 2005 19:37:44 -0800 (PST)), Linus Torvalds <[email protected]> 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
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
David S. Miller wrote:
> On Wed, 02 Mar 2005 22:40:57 -0500
> Jeff Garzik <[email protected]> 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
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!"
Dave Jones <[email protected]> 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.
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
On Wednesday 02 March 2005 22:17, Andrew Morton wrote:
>Gene Heskett <[email protected]> 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.
On Wed, 02 Mar 2005 23:46:22 -0500
Jeff Garzik <[email protected]> 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.
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.
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 - [email protected] - Agoura, CA
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 - [email protected] - Agoura, CA
On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> Dave Jones <[email protected]> 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
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. ;)
Dave Jones wrote:
> On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> > Dave Jones <[email protected]> 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
On Wed, 2 Mar 2005 21:08:07 -0800
Russell Miller <[email protected]> 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 :-)
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
> 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
David S. Miller wrote:
> On Wed, 02 Mar 2005 23:46:22 -0500
> Jeff Garzik <[email protected]> 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
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
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
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
>>>>> "Greg" == Greg KH <[email protected]> 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
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
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
--- Willy Tarreau <[email protected]> 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.
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
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
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
Jeff Garzik <[email protected]> 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...)
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 <[email protected]>
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
Jeff Garzik <[email protected]> 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, [email protected]
[PATCH] r8169: removal of unused #define
Removal of unused #define
Signed-off-by: Jon Mason <[email protected]>
Signed-off-by: Francois Romieu <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
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.
>
> 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.
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
Andrew Morton wrote:
> Jeff Garzik <[email protected]> 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
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 <[email protected]>
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.
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.
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
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 <[email protected]>
Jeff Garzik <[email protected]> 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..
Randy.Dunlap ([email protected]) 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 <[email protected]>
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 <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
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
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".)
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
On Thu, Mar 03, 2005 at 02:15:06AM -0800, Andrew Morton wrote:
> Jeff Garzik <[email protected]> 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
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
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
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.
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
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
Wichert Akkerman <[email protected]> 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 ;)
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/
On Thu, 03 Mar 2005 11:29:07 +0100, Prakash Punnoor <[email protected]> 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: [email protected]
hello: ciarrop
paoloc.blogspot.com
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/
On Wednesday March 2, [email protected] wrote:
> On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <[email protected]> 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
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
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.
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
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 <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
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
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
On 2005-03-02T15:23:49, Greg KH <[email protected]> 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 <[email protected]>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
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 <[email protected]> 1.650.933.1373, 1.925.600.0401
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
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!)
* David S. Miller 2005-03-02 20:05
> On Wed, 02 Mar 2005 21:32:23 -0500
> Jeff Garzik <[email protected]> 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.
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
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 <[email protected]>
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
* Jeff Garzik ([email protected]) 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
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
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
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 <[email protected]> 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
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 --> []
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
Linus Torvalds <[email protected]> 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
* Linus Torvalds ([email protected]) 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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*
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
On Thu, 3 Mar 2005 11:48:39 +0000 (GMT)
Anton Altaparmakov <[email protected]> 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.
On Thu, 3 Mar 2005, Neil Brown wrote:
> On Wednesday March 2, [email protected] wrote:
>> On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <[email protected]> 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
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
* Linus Torvalds ([email protected]) 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
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
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
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
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
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
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
> 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
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
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
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
Andries Brouwer <[email protected]> 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
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
On Thu, 03 Mar 2005 14:52:21 -0500
Jeff Garzik <[email protected]> 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.
Jeff Garzik <[email protected]> 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
David S. Miller wrote:
> On Thu, 03 Mar 2005 14:52:21 -0500
> Jeff Garzik <[email protected]> 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
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
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
Chris Wright <[email protected]> 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
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
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
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
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
El Thu, 3 Mar 2005 00:21:01 -0500,
Dave Jones <[email protected]> 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.
Linus Torvalds <[email protected]> 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
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
Andries Brouwer <[email protected]> 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.
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
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
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
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
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
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.
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
> 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
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
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
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....
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.
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
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)
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
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
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
Greg KH <[email protected]> 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.
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 ;)
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.
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.
Dave Jones ([email protected]) 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
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.
Linus Torvalds <[email protected]> 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.
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------
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.
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
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.
Andrea Arcangeli <[email protected]> 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?
Alan Cox <[email protected]> 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.
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.
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.
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 ;)
Andrew Morton wrote:
> Alan Cox <[email protected]> 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
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.
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
Jeff Garzik <[email protected]> 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?
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
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
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 http://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
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
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
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 http://www.kernel.org and
http://www.kernelnewbies.org, to make casual testing even easier.
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.
-----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-----
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
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
Jeff Garzik <[email protected]> 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.
Jochen Striepe <[email protected]> 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.
> 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
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
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 http://www.kernel.org and
> http://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/
Jeff Garzik <[email protected]> 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 ;)
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
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 <[email protected]>
> To: Jeff Garzik <[email protected]>
> Cc: Alan Cox <[email protected]>, Linus Torvalds <[email protected]>,
> Linux Kernel Mailing List <[email protected]>
> 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 [email protected]
> 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
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.
Thomas Gleixner <[email protected]> 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.
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
Jens Axboe <[email protected]> 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.
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 <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Andrew Morton wrote:
> Thomas Gleixner <[email protected]> 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
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
Gene Heskett <[email protected]> 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
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
>-rc just means "please start testing", not "deploy me on your corporate
>database server".
>
>
Does it? Where on http://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 http://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.
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 ?
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
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
On Gwe, 2005-03-04 at 05:34, Andrew Morton wrote:
> Jeff Garzik <[email protected]> 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
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
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
Alan Cox <[email protected]> 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.
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
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
On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> Russell King <[email protected]> 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
Russell King <[email protected]> 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?
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
On Fri, Mar 04, 2005 at 03:44:10AM -0800, Andrew Morton wrote:
> Russell King <[email protected]> wrote:
> > On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> > > Russell King <[email protected]> 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
Russell King <[email protected]> wrote:
>
> On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote:
> > Russell King <[email protected]> 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.
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
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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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.
El Fri, 4 Mar 2005 11:06:33 +0000,
Russell King <[email protected]> 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)
Alan Cox <[email protected]> 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?
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
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
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
> 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
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
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
On Fri, 4 Mar 2005, Andrew Morton wrote:
>
> Jens Axboe <[email protected]> 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
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
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
On Thu, 3 Mar 2005, Neil Brown wrote:
> On Wednesday March 2, [email protected] 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
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
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/
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
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
...
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
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
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
Linus Torvalds <[email protected]> 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 <[email protected]>
GPL'ed software available at: http://pyropus.ca/software/
-----------------------------------------------------------------------
On Fri, 4 Mar 2005, Linus Torvalds wrote:
>
>
> On Fri, 4 Mar 2005, Andrew Morton wrote:
> >
> > Jens Axboe <[email protected]> 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
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
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
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
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
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
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
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.
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/
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
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
> -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
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
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
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 <[email protected]>
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
=============================
Russell King <[email protected]> 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.
On Fri, Mar 04, 2005 at 02:48:08PM -0800, Andrew Morton wrote:
> Russell King <[email protected]> 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
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
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.
"Richard Purdie" <[email protected]> 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.
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
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
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
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: [email protected]
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
On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
<[email protected]> 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
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.
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 <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
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
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..
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.
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).
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
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!
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"
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.
--- "Randy.Dunlap" <[email protected]> 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/
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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
--- Zwane Mwaikambo <[email protected]> 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/
--- Dave Jones <[email protected]> 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
--- Jeff Garzik <[email protected]> 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/
szonyi calin <[email protected]> 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.
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
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote:
> --- Dave Jones <[email protected]> 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
--- Jeff Garzik <[email protected]> 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/
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
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-.
--- Lee Revell <[email protected]> wrote:
> On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote:
> > --- Dave Jones <[email protected]> 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/
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
>>>>> "Andrew" == Andrew Morton <[email protected]> writes:
Andrew> Linus Torvalds <[email protected]> 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.
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!!
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 <[email protected]> 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
Russell King <[email protected]> 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.
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 <[email protected]> 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
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
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
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
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
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
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 <[email protected]>
--- 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
> 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
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
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
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
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
