Re: RFD: Kernel release numbering

[Thomas Gleixner]

On Thu, 2005-03-03 at 08:23 -0800, Linus Torvalds wrote:
> But look at how to solve it. The _logical_ solution is to have a third
> line of defense: we have the -mm trees (wild and wacky patches), and we
> have my tree (hopefully not wacky any more), and it would be good to have
> a third level tree (which I'm just not interested in, because that one
> doesn't do any development any more) which only takes the "so totally not
> wild that it's really boring" patches.
> 
> In fact, if somebody maintained that kind of tree, especially in BK, it 
> would be trivial for me to just pull from it every once in a while (like 
> ever _day_ if necessary). But for that to work, then that tree would have 
> to be about so _obviously_ not wild patches that it's a no-brainer.
> 
> So what's the problem with this approach? It would seem to make everybody
> happy: it would reduce my load, it would give people the alternate "2.6.x
> base kernel plus fixes only" parallell track, and it would _not_ have the 
> testability issue (because I think a lot of people would be happy to test 
> that tree, and if it was always based on the last 2.6.x release, there 
> would be no issues.

This way you have a fixup tree for the latest 2.6.x release, but does
not resolve the problem of the release quality itself.

It makes more sense to do

2.6.x-pre1 .. preX in your tree until you feel comfortable to move it
into the release tree, where it starts from

2.6.x-rc1 .. rcX bugfix only up to the final release.

>From the release to the next -preX to -rc1 move this tree only handles
the real trivial and urgent fixes and produces 2.6.x.y updates. When the
next -rc1 appears the previous 2.6.x.y is frozen and never touched
again.

This way you have ongoing development in your tree and the -rcX releases
might find more testers than now.

> I'll tell you what the problem is: I don't think you'll find anybody to do
> the parallell "only trivial patches" tree. They'll go crazy in a couple of
> weeks. Why? Because it's a _damn_ hard problem. Where do you draw the
> line? What's an acceptable patch? And if you get it wrong, people will
> complain _very_ loudly, since by now you've "promised" them a kernel that
> is better than the mainline. In other words: there's almost zero glory,
> there are no interesting problems, and there will absolutely be people who 
> claim that you're a dick-head and worse, probably on a weekly basis.

I think when the rules are clear and some gratification would be
available you might find somebody to jump on this train. 

tglx


-
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/