Re: Stop the Linux kernel madness

[Lars Marowsky-Bree <lmb@suse.de>]

On 2004-06-18T23:17:57,
   Jens Axboe <axboe@suse.de> said:

> > Problem is, what happens if vendor X ships a feature and that feature is
> > deemed unacceptable for the kernel.org kernel?
> Very good question, as these features/patches are often the ones that
> are ugliest and the hardest to maintain. Or the ones that make you
> slightly source incompatible with mainline, which is always ugly.

I'm afraid that to a certain and hopefully very limitted extend that's
why the distributors need to pay kernel maintainers themselves... *sigh*
I fear the answer is called "business reason", and this time it affects
the kernel, the next time someone does it with gcc, glibc or whatever.

All engineering can do is to kick back as hard as possible and support
eachother by publically kicking back when someone else is forced to do
it - so they can run to their management and complain "see what kind of
bad publicity that gave us!" and hopefully make them at least raise the
bar (& price) of doing it next time ;-)

> > But we then need to do it all again in 2.8.x.  It's hard to see how to fix
> > this apart from either merging everything into the main tree or dropping
> > things from vendor trees.  Or waiting for someone to come up with an
> > acceptable form of whatever it is the patch does.
> Wish I had an answer for that. Things can and do get dropped from vendor
> trees, doesn't cover all cases naturally.

The "waiting for someone.*does." approach before merging into mainline
is the only sane answer IMHO; merging a patch in a vendor kernel should
ultimately lead to that, or at least I'm very convinced that's our goal.

It's not _always_ reached of course, in which case either a feature is
obsoleted, a migration to a different implementation of said feature
needed for customers, or one gets (grudgingly) to carry the patch until
the next major lifecycle change. And 2.4 was hopefully the very height
of those cases and we are settling down again.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett