Messages in this thread | | | Subject | Re: RFD: Kernel release numbering | From | Thomas Gleixner <> | Date | Thu, 03 Mar 2005 17:55:59 +0100 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |