[linux-elitists] New Kernel Dev model...

Greg KH greg@kroah.com
Thu Jul 22 12:00:44 PDT 2004

On Thu, Jul 22, 2004 at 01:36:51PM -0400, Greg Folkert wrote:
> Greg Kroah-Hartman how dare you test out the NEW Development model for
> the Linux Kernel. </joke>
> http://kerneltrap.org/node/view/3513

Yeah, I need to remember Pat Mochel's advice, "Never write email while
drunk" :)

I really did it to point out a flaw in our new development model, we now
have no way to officially depreciate a feature.  Which has caused some
good talk about how we need to handle this.

> I have mixed feelings about this... leaving the stabilizations to the
> Vendors/Distros... It was already happening... but why make it defacto.

You just answered it yourself.  It was already happening.  And it's how
it has happened for years.

Combine that with the pain that we all went through with backporting 2.5
stuff to 2.4 due to real users' need, and this new way made a lot of
sense.  What makes more sense is the fact that the Linus-Andrew tag team
really works out well.  So much so that we are a bit scared to change

The proof of this is due to the HUGE number of lines of code that has
changed over the recent months.  Jon reported the 10Mb number.  He
didn't hear the other numbers that Andrew told us later on.  Something
like 2/3 of the lines of the kernel have been modified over the past 3
months.  He had real numbers, but see the above advice I need to give
myself as an excuse why I don't actually recall the true numbers.

> I know, this has been discussed in detail (not enough IMHO) and I just
> would really like a direct view from someone involved in the mess.
> (where mess == project)

I'm there.  And I think it rocks.  If this works, this will benefit
users way more than they can ever expect.  If you ran 2.5 all during the
past 3 years, you know what I mean.  We had stuff in there so long ago
that made 2.4 mainline look so crappy.  Now all the world will have this
goodness, much sooner.

And, for the real horrible stuff that will cause massive breakage (like
the page table rework), that stuff will be in a 2.7 branch.  And then,
using bitkeeper, all of the 2.6 stuff will continue to get pulled into
2.7, ensuring we don't all have to do double the work for our bugfixes.
If the 2.7 stuff doesn't work out, we can delete that whole tree, and
start again, with no loss of work other than the stuff that made us give
up on it.

> I like development models that are Dev->Test->QA->RC->Release for
> Production builds.

Great, use a "Enterprise Certified" version of Linux for that, if that
is what you, or your customers want.  Lots of people will gladly provide
you that service.

The rest of us will be over here, madly innovating away, generally
having a wonderful time.

I hope this has helped convince you.  Realize that this isn't a radical
change as to what has been happening since the day 2.6.0 came out.  We
are just actually publicising it, for those who weren't paying

Hell, I just convinced Rusty that breaking in-kernel APIs in a "stable"
kernel is a good thing, something must be working for us :)

greg k-h

More information about the linux-elitists mailing list