lkml.org 
[lkml]   [2011]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] omap changes for v2.6.39 merge window
    On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
    >
    > So we need help!  If core kernel people could get off their X86 stool
    > and get down in the ARM mud to help sort out this mess that would be
    > really nice (thanks tglx).  Until then all that the few of us can do is
    > to contain the flood and hope for the best, and so far things being as
    > they are have still worked surprisingly well in practice for users.  If
    > compensation is a concern then I think Linaro might be able to arrange
    > something.

    The thing is, maintainers don't scale.

    The only way to get quality code is to try to improve the quality from
    the "leaf nodes", because otherwise you'll always end up playing
    catch-up. You'll get new bad code faster than you can clean it up.

    I've told people this before, and I'll tell it again: when I flame
    submaintainers, they should try to push the pain down. I'm not really
    asking those submaintainers to clean up all the stuff they are
    getting: I'm basically asking people to say "no", or at least push
    back a lot, and argue with the people who send you code. Tell them
    what you don't like about the code, and tell them that you can't take
    it any more.

    > And we can't count on vendor people doing this work.  They are all busy
    > porting the kernel to their next SOC version so they can win the next
    > big Android hardware design, and doing so with our kernel quality
    > standards is already quite a struggle for them.

    This really isn't the argument. The argument should be that if they
    want their code up-stream, they need to do a good job. If they don't,
    why should you take it at all?

    > What is going on at the moment is some effort to introduce DT support to
    > ARM.  The core support is there, but that is useless until platform code
    > is moved to it, and corresponding work is put into bootloaders, etc.
    > That is progressing... slowly.

    How about not moving platform code TO it, but at least saying that you
    won't accept new platform code that doesn't use it? When somebody
    sends you a new platform, just say "no" if it's another copy-paste job
    or another "add yet another #ifdef or conditional to a messy driver".

    > But we also need some slack wrt number of lines changed.  An increased
    > consolidation effort will create more churn not less, at least for a
    > while.  The OMAP clock merge conflict was the result of some cleanup
    > which will make further consolidation easier.

    Umm. The whole "number of lines of code" thing has become a total red herring.

    THAT IS NOT WHY I STARTED TO COMPLAIN!

    The reason I point out the number of lines of code is because it's one
    of the more obvious _symptoms_ of the problem.

    But trust me, if you start doing a better job at platform code, I
    won't be complaining when I get lots of deleted code, or when I start
    getting devicetree descriptions instead of new drivers.

    So "number of lines of code" and "massive churn" is a problem, but
    look at how I'm not complaining about the drivers/ subdirectory, which
    is still the bulk of all lines in the kernel by far. I may complain
    about particular subsystems in drivers (gpu..) for other reasons, but
    it's not "lines of code" per se.

    In the case of ARM, the reason I point out the size of the arch/arm is
    because it's illustrative of just how _different_ ARM is from the
    other architectures. And those differences are pretty much all about
    the board/platform issues.

    Linus
    --
    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: 2011-03-31 22:07    [W:4.374 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site