lkml.org 
[lkml]   [2004]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Stop the Linux kernel madness
    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

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

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:3.365 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site