Easier Patch Submission? Is it possible?

[Frédéric Buclin]

Le 20. 01. 10 09:26, Jochen Wiedmann a écrit :
> At that time, my proposal was refused, mostly with the argument that
> the contributior "feels better", because the patch is "100% his".

I remember this discussion. There were two points in favor of several
iterations: the first one is the one you mentioned, i.e. letting the
contributor attach a complete and correct patch, so he really has the
feeling that he did the whole job himself (and to get all the merit).
The second point was to make contributors "better", i.e. they understand
the points we would like them to make better so that they do it right
the next time they contribute. Now the main disadvantages of this
approach are 1) it takes a lot of time from the reviewer, as you said,
and 2) there is a risk that the contributor becomes demotivated and
leaves (because for him, his patch is working, and doesn't care about
your nits or the refactoring you suggest him to do).

To avoid these problems, what I do more and more often is either 1) r+
the patch and mention that I will do the numerous "fixes on checkin"
myself, to avoid extra loops and to not demotivate the contributor, or
2) I ask the contributor if he agrees that I finalize his patch myself,
so that he doesn't think I'm trying to steal his work and get all the
credit. I think that's a better choice, but this requires some free time
from the reviewer to update and test the patch, and is only doable if
the reviewer has a real interest in the fix/feature and/or is able to
reproduce the issue.

>From what I can see, mkanat is following the same path, i.e. I see him
doing a lot of fixes on checkin himself to not demotivate valuable
contributors/contributions. But if we have no time and/or interest to do
the fixes ourselves, we have no other choices than to r- the patch and
to ask for an updated one.

LpSolit