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 <[email protected]> wrote:
* Rene Herman <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
