[Ksummit-2012-discuss] [ATTEND] Your upstream maintainer just isn't that into you...
H. Peter Anvin
hpa at zytor.com
Wed Jun 27 13:33:10 UTC 2012
On 06/25/2012 06:44 PM, Dan Williams wrote:
> Can we do a better job of bounding the maximum latency for acceptance
> or rejection of a patch?
I would like to remind people that there is a flipside to this argument.
We have had a number of fairly prolific contributors who produce large
amounts of very low-quality work, and who seem to think that it is the
job of the upstream maintainer to give timely, very detailed feedback at
exactly what they are doing wrong.
Doing that can easily consume more of the maintainer's time than it did
the contributor (especially since this class of contributor invariably
produce patch descriptions which are as bad or worse as their code, thus
making it hard to figure out even what problem they are trying to
solve), and either way can take more time than it would have taken the
maintainer to write the code in the first place -- and wouldn't have had
the timing issues, either.
This gets old very very fast, as the "contributor" is effectively
issuing a DoS on the maintainer. My experience, too, is that
contributors who fall into this category are completely immune to hints
that what they are doing isn't productive, and although many of us can
bark pretty hard at times, it is still very unpleasant when you have
spent a bunch of times trying to get a contributor to improve to get
zero results, and then you end up with the choice of "ignore them or
tell them off", but you *have* to eventually do one or the other.
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
More information about the Ksummit-2012-discuss