Re: RFD: Kernel release numbering

From: Bill Davidsen
Date: Tue Mar 08 2005 - 16:54:33 EST

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.


- a vetting process. You'd have ten people, and five of them would have to sign off on the patch, and even a single veto would shoot it down.

Way overkill, if the maintainer can be trusted to either understand or pass the vetting to someone who does, more eyes increase the probability if someone rejecting a valid patch because they didn't understand it.

Again, this is really to protect the sucker, and make it possible to
work: I don't think this can work with a creative person (everybody
else calls me "flaky", and I much prefer that "creative" word, it sounds
so much better), which I personally believe means that we don't _want_
people like Alan, Andrea, Andrew etc etc that have historically maintained
their own trees that sometimes have tried to do something like this.

I doubt he feels the need, paperwork for the sake of paperwork...

- Finally: this tree never has any history past the "last release". When
a new kernel comes, the tree is frozen, and never to be touched again.

Which bouncds the effort to maintain a stable tree.

Does this mean that some patches would never go into this tree? Yes. It
would mean that patches that some people might feel very _strongly_ are
good patches would never ever show up in this tree, but on the other hand,
I can see this tree being useful regardless, and I think the lack of
flexibility in this case is actually the whole _point_ of the tree. The lack of flexibility is the very thing that makes this be the kind of base that anybody else can then hang their own patches on top of. There should never be a situation where "I'd like that tree, but I think xxxx was done wrong".

As must be to be stable.

Might something like this make people happier? (I wrote "happy" rather
than "happier" at first, but let's face it, people are better at whining
than they are at being happy ;)

I think this is just what's needed, and it addresses both the delay in getting new features in as well as delay in getting fixes in a stable kernel.

-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at