lkml.org 
[lkml]   [2011]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] omap changes for v2.6.39 merge window

    * David Brown <davidb@codeaurora.org> wrote:

    > When we push back, there is a good chance they just won't bother, not because
    > they don't want to do it, but because it doesn't fit a schedule, and there is
    > already something else for them to work on.
    >
    > So what's the right answer here. [...]

    IMO the right answer is what Linus and Thomas outlined:

    1) provide a small number of clean examples and clean abstractions
    2) to not pull new crap from that point on
    3) do this gradually but consistently

    I.e. make all your requirements technical and actionable - avoid sweeping,
    impossible to meet requirements. Do not require people to clean up all of the
    existing mess straight away (they cannot realistically do it), do not summarily
    block the flow of patches, but be firm about drawing a line in the sand and be
    firm about not introducing new mess in a gradually growing list of well-chosen
    areas of focus.

    Rinse, repeat.

    If companies do not 'bother to push upstream', then management will eventually
    notice negative economic consequences:

    - Higher short-term production costs: upstream feedback/review/testing
    improves the product, so the lack of upstream feedback/review/testing
    increases the production costs of the product.

    - Higher long-term production costs: gradually slower SoC development due to a
    morass of out-of-tree hacks that werent pushed upstream causing gradually
    higher development costs. This means higher payroll costs and longer time to
    market - in which time more flexible competitors can beat you.

    - Brain drain: developers like to show their good work upstream as well, not
    just in some ship-and-forget out-of-tree kernel. Good developers will
    gravitate towards SoC companies that encourage them to work upstream.
    No matter how good of a business idea a company has if there's no good
    developers.

    - Less revenue: a product can not possibly be more appealing to SoC customers
    if the upstream Linux kernel does not support it. As ARM moves up the food
    chain towards more complex, higher profit margin products longer term
    thinking gains foothold gradually.

    - Competitive disadvantages: most SoC competitors push their changes upstream,
    so they get free development assistance, they get free exposure, they get
    free PR and they get opportunities. Not pushing upstream is a lost
    opportunity.

    All of these effects translate into real $$$$$$$ and affect the bottom line
    very directly, both short and long term. These costs also increase with time so
    they are not fixed.

    If management does not actively encourage upstream-quality changes then
    management will have to justify why they exposed the company to these extra
    costs, complications and risks - just to save on the relatively minor (and
    fixed) cost of working with upstream.

    If despite all that management still believes (rightly or wrongly) that it's
    cheaper for the company to do low quality throw-away code and does not care
    about any of the short and long-term costs listed above then this really means
    that they really do not care about you or about the upstream kernel - so they
    do not exist as far as the upstream kernel is concerned.

    Why should you then reward them with pulling crap and why should you be willing
    to invest future maintenance overhead into their "we do not care about you"
    solution?

    Working with upstream is a quid pro quo with plenty of advantages on both
    sides, which gives maintainers a heck of a leverage to push back on crap while
    still having all the incentives in the world to help produce a high quality
    kernel.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2011-04-01 09:47    [W:0.026 / U:93.292 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site