Kindness and open-source projects

Posted Jul 2, 2018 7:54 UTC (Mon) by mjthayer (guest, #39183)
In reply to: Kindness and open-source projects by k8to
Parent article: Kindness and open-source projects

With one-time contributions it can be quicker just to rework a patch yourself rather than work with the contributor to get it into just the right format and state of testing. But the patch-which-doesn't-fit-your-standards can still save you a great deal of time analysing a problem and can make the difference between a bug being worth the time to fix or not. Is the reason why many people still insist on the contributor reworking the patch because of the (mainly) git chain of authorship principle?

Kindness and open-source projects

Posted Jul 2, 2018 22:18 UTC (Mon) by xtifr (guest, #143) [Link] (5 responses)

I suspect it's more likely to be a "learn our standards so you can become a regular contributor" thing. Often done without asking whether the person has any interest in becoming a regular contributor, of course, but then hope springs eternal. :)

Chain of credit/blame can also be a factor, of course.

Kindness and open-source projects

Posted Jul 4, 2018 7:33 UTC (Wed) by osma (subscriber, #6912) [Link] (4 responses)

Speaking as both maintainer and occasional contributor, these are exactly the reasons.

If, as a maintainer, I receive a pull request which is mostly OK, I try to ask the contributor to rework it instead of fixing it on my own, even though it might be more work. This way, the author gets the credit, and maybe will come back with another PR later - who knows. But if it's obvious that the contributor is not interested in reworking the patch, I will try to add my changes on top and merge both at the same time, if that's possible.

As a contributor, I like it when my patch gets incorporated upstream. It's frustrating when the maintainer puts in his/her own fix instead of taking mine.

Kindness and open-source projects

Posted Jul 4, 2018 7:48 UTC (Wed) by mjthayer (guest, #39183) [Link] (3 responses)

> As a contributor, I like it when my patch gets incorporated upstream. It's frustrating when the maintainer puts in his/her own fix instead of taking mine.

We tend to credit the submitter even when we rework the patch quite substantially. Of course, in Subversion there is no direct patch-to-commit conversion like in Git, so the bar to reworking is probably lower.

Kindness and open-source projects

Posted Jul 4, 2018 13:29 UTC (Wed) by gioele (subscriber, #61675) [Link] (2 responses)

> > As a contributor, I like it when my patch gets incorporated upstream. It's frustrating when the maintainer puts in his/her own fix instead of taking mine.

> We tend to credit the submitter even when we rework the patch quite substantially. Of course, in Subversion there is no direct patch-to-commit conversion like in Git, so the bar to reworking is probably lower.

At the same time, putting somebody else's name on something they haven't authored may be perilous. What if that commit ends up introducing a subtle bug in the reworked part?

I personally see only three acceptable choices (after a bit of back and forth with the original contributor):

1. if the commit is OK, let's just merge it;
2. if the commit is not OK, I will rework it and add a Reported-By tag;
3. if the commit is _almost_ OK, I will merge the commit in another branch, do what needs to be done in another commit in that branch and finally merge that branch.

Kindness and open-source projects

Posted Jul 5, 2018 13:19 UTC (Thu) by ecree (guest, #95790) [Link]

The kernel solution for the "almost OK" case is to put a square-bracketed note in between SOB lines, to indicate a sign-off under option (b) of the DCoO instead of option (c). Something like (example from SubmittingPatches):

Signed-off-by: Random J Developer <random@developer.example.org>
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>

which is explicitly described as being to avoid "mak[ing] him endorse your bugs". It doesn't come up very often, though, since most issues get resolved fine by patch ping-pong.

Meanwhile, for your case (2) I think Suggested-By: is more appropriate than Reported-By: if your patch really is a rework of the contribution rather than just a new patch to fix the same bug.

Kindness and open-source projects

Posted Jul 5, 2018 19:21 UTC (Thu) by xtifr (guest, #143) [Link]

> At the same time, putting somebody else's name on something they haven't authored may be perilous.

If you give them *exclusive* credit when the work isn't exclusively theirs, sure. But there shouldn't be a problem with giving *all* the authors credit if it's a collaborative work. In fact, that's so clearly the right thing to do that I'm surprised there's any question about it.

When someone sends me a patch and I end up reworking it, I have never considered *not* saying (at the very least): "based on work by so-and-so." Whether they end up on blame lists may depend on a variety of factors, depending on how much reworking was needed, but at the very least, I make sure the name ends up in commit messages and changelogs.

(Aside: I also don't care whether upstream takes my patches directly or rewrites them. The important thing to me is that the problem is fixed. I do, of course, like getting some appropriate amount of credit for my help, but unless it's a project where I have plans to get more involved, I don't necessarily *want* to have to jump through the hoops of learning all the project's coding standards.)

Kindness and open-source projects

Posted Jul 4, 2018 8:53 UTC (Wed) by karkhaz (subscriber, #99844) [Link]

> Is the reason why many people still insist on the contributor reworking the patch because of the (mainly) git chain of authorship principle?

For me, this depends on how closely I associate with the project in question. If I'm making a drive-by contribution, I honestly don't care if somebody takes my patch and runs off with it; as long as the bug gets fixed, it's all good. But if I'm making regular contributions to a project, I appreciate having one of the maintainers walk me though what the project's norms and guidelines are and helping me to rework it, so that I can submit a patch more smoothly in the future, and also get recognition within the project.

For drive-by contributions, I appreciate that it's a waste of the maintainer's time to explain the unwritten rules to everybody time after time, because the effort is wasted on somebody who won't be contributing much in the future. OTOH, I do realise that a lot of folks will start with a drive-by to "test the waters" and see how welcoming and responsive a project is, before committing to sending more substantial patches...

I now wonder whether it would be productive for some projects to officially have drive-bys as a category in-between feature requests and pull requests.

- Feature request: I ask nicely for a feature, hoping that somebody else will implement it

- Drive-by: I ask nicely for a feature, implementing an initial patch to get the ball rolling. But I don't have the time or resources to follow through, so anybody should feel free to write the patch properly and claim authorship, or just apply the patch if it is already good enough.

- Pull request: I ask nicely for a feature, write a patch, and commit to working with the maintainers to rework and polish the patch until it gets merged in.