Re: RFD: Kernel release numbering

[Greg KH]

On Thu, Mar 03, 2005 at 12:52:52PM -0500, Daniel Barkalow wrote:
> On Thu, 3 Mar 2005, Linus Torvalds wrote:
> 
> >  - some very _technical_ and objective rules on patches. And they should 
> >    limit the patches severely, so that people can never blame the sucker 
> >    who does the job. For example, I would suggest that "size" be one hard 
> >    technical rule. If the patch is more than 100 lines (with context) in
> >    size, it's not trivial any more. Really. Two big screenfuls (or four, 
> >    for people who still use the ISO-ANSI standard 80x24 vt100)
> 
> One thing that's worth pointing out is that sometimes the 20-line patch is
> sufficient to solve the problem, but is lousy code. That's fine for a tree
> that will be frozen in a couple of months after only getting little fixes
> to other files, but mainline should get a real fix, which wouldn't be
> acceptable in the sucker tree. So 2.6.(x+1) shouldn't automatically get
> 2.6.x.y. Should reverting a 200-line patch which turned out to need
> another 200 lines to work be acceptable?

It's simple in bk to revert a patch.  So in this instance, when the
2.6.x person pulls in the 2.6.x.y tree, they just revert the offending
patch, and move on.  Actually, the maintainer applying the offending
patch would do it, in their tree, before they sent it to Linus.  Or they
do it by the normal patch way, if they don't use bk.

So, not a problem.

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

If it's a bugfix for the core, that met the above rules, I wouldn't mind
it at all.  See the sysfs core patch that made it in between 2.6.11-rc5
and 2.6.11 for such an example.

thanks,

greg k-h
-
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/