lkml.org 
[lkml]   [2007]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ck] Re: -mm merge plans for 2.6.23
    Hi Ingo,

    [ Going off-topic, nothing related to swap/prefetch/etc. Just getting
    a hang of how development goes on here ... ]

    On 7/25/07, Ingo Molnar <mingo@elte.hu> wrote:
    >
    > * Rene Herman <rene.herman@gmail.com> wrote:
    >
    > > Nick Piggin is the person to convince it seems and if I've read things
    > > right (I only stepped into this thing at the updatedb mention, so
    > > maybe I haven't) his main question is _why_ the hell it helps
    > > updatedb. [...]
    >
    > btw., i'd like to make this clear: if you want stuff to go upstream, do
    > not concentrate on 'convincing the maintainer'.

    It's not so easy or clear-cut, see below.

    > Instead concentrate on understanding the _problem_,

    Of course -- that's a given.

    > concentrate on
    > making sure that both you and the maintainer understands the problem
    > correctly,

    This itself may require some "convincing" to do. What if the maintainer
    just doesn't recognize the problem? Note that the development model
    here is more about the "social" thing than purely a "technical" thing.
    People do handwave, possibly due to innocent misunderstandings,
    possibly without. Often it's just a case of seeing different reasons behind
    the "problematic behaviour". Or it could be a case of all of the above.

    > possibly write some testcase that clearly exposes it, and

    Oh yes -- that'll be helpful, but definitely not necessarily a prerequisite
    for all issues, and then you can't even expect everybody to write or
    test/benchmark with testcases. (oh, btw, this is assuming you do find
    consensus on a testcase)

    > help the maintainer debug the problem.

    Umm ... well. Should this "dance-with-the-maintainer" and all be really
    necessary? What you're saying is easy if a "bug" is simple and objective,
    with mathematically few (probably just one) possible correct solutions.
    Often (most often, in fact) it's a subjective issue -- could be about APIs,
    high level design, tradeoffs, even little implementation nits ... with one
    person wanting to do it one way, another thinks there's something hacky
    or "band-aidy" about it and a more beautiful/elegant solution exists elsewhere.
    I think there's a similar deadlock here (?)

    > _Optionally_, if you find joy in
    > it, you are also free to write a proposed solution for that problem

    Oh yes. But why "optionally"? This is *precisely* what the spirit of
    development in such open / distributed projects is ... unless Linux
    wants to die the same, slow, ivory-towered, miserable death that
    *BSD have.

    > and
    > submit it to the maintainer.

    Umm, ok ... pretty unlikely Linus or Andrew would take patches for any
    kernel subsystem (that isn't obvious/trivial) from anybody just like that,
    so you do need to Cc: the ones they trust (maintainer) to ensure they
    review/ack your work and pick it up.

    > But a "here is a solution, take it or leave it" approach,

    Agreed. That's definitely not the way to go.

    > before having
    > communicated the problem to the maintainer

    Umm, well this could depend from problem-to-problem.

    > and before having debugged
    > the problem

    Again, agreed -- but people can plausibly see different root causes for
    the same symptoms -- and different solutions.

    > is the wrong way around. It might still work out fine if the
    > solution is correct (especially if the patch is small and obvious), but
    > if there are any non-trivial tradeoffs involved, or if nontrivial amount
    > of code is involved, you might see your patch at the end of a really
    > long (and constantly growing) waiting list of patches.

    That's the whole point. For non-trivial / non-obvious / subjective issues,
    the "process" you laid out above could itself become a problem ...

    Satyam
    -
    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: 2007-07-25 19:35    [W:4.255 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site