Re: RFD: Kernel release numbering

[James Bourne]

On Thu, 3 Mar 2005, Linus Torvalds wrote:

> On Thu, 3 Mar 2005, Jeff Garzik wrote:
> > 
> > We have all these problems precisely because _nobody_ is saying "I'm 
> > only going to accept bug fixes".  We _need_ some amount of release 
> > engineering.  Right now we basically have none.
> 
> I agree that this is one of the main problems.
> 
> 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.

Sorry, I'm just on the end of this thread but I wanted to put in my 2 bits,

I was maintaining this type of tree for 2.4 before.  It was well received by
those who used it and it was stable (ssssh, I'm still running that puppy on
a couple well hidden 7.2 servers).

The key then was to only put in patches that fixed issues.  If it was a hard
factual solution to a problem then it went into the patch.  BTW, it was just
that, a patch (or set of patches) not actually a seperate tree.  It was
completely focused on stability as that's what I needed for work at the
time.

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

It was good for 2.4 and I think for 2.6, the legitimacy (coming from the top
down) will be a good thing.  It wasn't as widely received in 2.4 due to it
not being "officially sanctioned"...

BTW, it's not actually that much work.  Watching the list and getting feed
back on what works and what doesn't is all that it takes.  Naturally, there
will be a couple "frell, where was I when I did that" patches but that's
life in the semi-fast lane.

This will be a good thing.

Regards
James


-- 
James Bourne                  | Email:            jbourne@xxxxxxxxxxxx          
UNIX Systems Administration   | WWW:           http://www.hardrock.org
Custom UNIX Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  
-
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/