sure - but i was really not talking about from the user's perspective,
but from the enterprising kernel developer's perspective who'd like to
solve a particular problem. And the nice thing about concentrating on
the problem: if you do that well, it does not really matter what the
maintainer thinks!
( Talking to the maintainer can of course be of enormous help in the
quest for understanding the problem and figuring out the best fix -
the maintainer will most likely know more about the subject than
yourself. More communication never hurts. It's an additional bonus if
you manage to convince the maintainer to take up the matter for
himself. It's not a given right though - a maintainer's main task is
to judge code that is being submitted, to keep a subsystem running
smoothly and to not let it regress - but otherwise there can easily be
different priorities of what tasks to tackle first, and in that sense
the maintainer is just one of the many overworked kernel developers
who has no real obligation what to tackle first. )
If the maintainer rejects something despite it being well-reasoned,
well-researched and robustly implemented with no tradeoffs and
maintainance problems at all then it's a bad maintainer. (but from all
i've seen in the past few years the VM maintainers do their job pretty
damn fine.) And note that i _do_ disagree with them in this particular
swap-prefetch case, but still, the non-merging of swap-prefetch was not
a final decision at all. It was more of a "hm, dunno, i still dont
really like it - shouldnt this be done differently? Could we debug this
a bit better?" reaction. Yes, it can be frustrating after more than one
year.
no, but Con is/was certainly more than capable to write testcases and to
debug various scenarios. That's the way how new maintainers are found
within Linux: people take matters in their own hands and improve a
subsystem so that they'll either peacefully co-work with the other
maintainers or they replace them (sometimes not so peacefully - like in
the IDE/SATA/PATA saga).
you dont _have to_ cooperative with the maintainer, but it's certainly
useful to work with good maintainers, if your goal is to improve Linux.
Or if for some reason communication is not working out fine then grow
into the job and replace the maintainer by doing a better job.
perhaps you misunderstood how i meant the 'optional': it is certainly
not required to write a solution for every problem you are reporting.
Best-case the maintainer picks the issue up and solves it. Worst-case
you get ignored. But you always have the option to take matters into
your own hands and solve the problem.
actually, it happens pretty frequently, and NACK-ing perfectly
reasonable patches is a sure way towards getting replaced as a
maintainer.
firstly, there's rarely any 'subjective' issue in maintainance
decisions, even when it comes to complex patches. The 'subjective' issue
becomes a factor mostly when a problem has not been researched well
enough, when it becomes more of a faith thing ('i believe it helps me')
than a fully fact-backed argument. Maintainers tend to dodge such issues
until they become more clearly fact-backed.
providing more and more facts gradually reduces the 'judgement/taste'
leeway of maintainers, down to an almost algorithmic level.
but in any case there's always the ultimate way out: prove that you can
do a better job yourself and replace the maintainer. But providing an
overwhelming, irresistable body of facts in favor of a patch does the
trick too in 99.9% of the cases.
Ingo
-
