Re: RFD: Kernel release numbering

[Eric Gaumer]

Greg KH wrote:
> On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
>
> > 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.
> >
> > Anybody?
>
>
> Well, I'm one person who has said that this would be a very tough
> problem to solve.  And hey, I like tough problems, so I'll volunteer to
> start this.  If I burn out, I'll take the responsibility of finding
> someone else to take it over.
>
> I really like the rules you've outlined, that makes it almost possible
> to achieve sanity.

How does what Linus outlined differ from splitting to 2.7? Isn't it the same thing with just
a different versioning scheme? In the end we have a stable 2.6 tree. What's the difference
between the 2.6 development tree and 2.7.

All that aside... why not make the "sucker tree" a breeding ground for new kernel hackers.
I've been trying to get more involved with kernel development (as are others) but it's tough
because things change so rapidly that once you finally figure it out, it has changed. As the
kernel matures into new versions it's getting much harder for guys coming out of school to
figure out. Sure you have that exceptional individual but maybe you're committing genocide
in the end.

If someone like Greg could lead this band of gypsies then that would be great. Most of the
more experienced hackers don't want to slow pace and do all this boring work but people like
myself would be honored to "pay our dues". We would feel free to ask some questions and see
a slower pace so we can learn. If patches are small and truly only fix bugs then wouldn't
you say this would be possible? In fact one criteria could be that if we can't understand
just what exactly the patch fixes then it probably doesn't belong in this tree? It's a win -
win situation. End users are happy and we start a semi-structured training camp.


--
"Education is what remains after one has forgotten everything he learned in school."
	- Albert Einstein

Attachment: signature.asc
Description: OpenPGP digital signature