Re: RFD: Kernel release numbering

[Daniel Barkalow]

On Thu, 3 Mar 2005, Linus Torvalds wrote:

>  - some very _technical_ and objective rules on patches. And they should 
>    limit the patches severely, so that people can never blame the sucker 
>    who does the job. For example, I would suggest that "size" be one hard 
>    technical rule. If the patch is more than 100 lines (with context) in
>    size, it's not trivial any more. Really. Two big screenfuls (or four, 
>    for people who still use the ISO-ANSI standard 80x24 vt100)

One thing that's worth pointing out is that sometimes the 20-line patch is
sufficient to solve the problem, but is lousy code. That's fine for a tree
that will be frozen in a couple of months after only getting little fixes
to other files, but mainline should get a real fix, which wouldn't be
acceptable in the sucker tree. So 2.6.(x+1) shouldn't automatically get
2.6.x.y. Should reverting a 200-line patch which turned out to need
another 200 lines to work be acceptable?

>    Also, I'd suggest that a _hard_ rule (ie nobody can override it) would 
>    also be that the problem causes an oops, a hang, or a real security
>    problem that somebody can come up with an exploit for (ie no "there
>    could be a two-instruction race" crap. Only "there is a race, and
>    here's how you exploit it"). The exploit wouldn't need to be full code 
>    that gets root, but an explanation of it, at least.

Similar rule for driver patches: you can patch a driver if it makes the 
device not work (but you couldn't patch the core)?

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

The good patches will show up in 2.6.(x+1).1, which should be
sufficient. It's not the same sucker tree, but it's a sucker tree.

	-Daniel
*This .sig left intentionally blank*

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