[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 mailing list