In open source projects there is typically a set of devs that have permissions to commit code – the committers -, and others that “pull request” or send patches, the “general public”.
I find a annoying when
-
the committer signs the commit with its own name, and writes in the commit message a “Thanks to …”.
-
the committer changes the patch before commit without asking if the original author agrees.
Given this two annoyances, I’m compelled to think that I should put myself in the other side and ask how should a core committer behave. Are these two particular situations expected?
I mean, is this the correct behaviour for building and maintaining an active community of “general public”?
EDIT:
I’m not asking if they have the right to do it or are legally obliged to do so. IMO a committer should not content himself to follow the law, but should be interested in building/maintaining the community within the project objectives constraints. That is what I’m asking for: how he should behave to accomplish this.
3
Ad 1.
That’s the reason git has separate author and committer entries in the commit metadata. So there it’s obvious they should keep the contributor in “author” and themselves as “committer”.
Git and Linux projects also have this ‘Signed-Off-By:’ tag. It is simply used as part of the commit itself – so we are back to “thanks to…”, just somewhat formalized – that lists all copyright holders as even single commit may have more than one. It happens often when the maintainer does significant changes to the contribution, but sometimes a half-done contribution is picked by somebody else and reworked, even several times over, so it’s not unusual to have 3 or more signatures on a commit.
Other version control systems (like Subversion) keep just the committer and track them automatically, so there is no other way than to mention the actual author in the message.
Ad 2.
The maintainer usually have some style they want to maintain and various interactions in the project may make them prefer some solution over another. So they often tweak submissions to match.
They have full right to do it. The original author did agree by putting the contribution under the project’s license! To qualify as open-source a license has to allow modification.
On the other hand, good maintainer distinguishes between integrator work and developer work and does not privilege themselves as developer. So as part of the integrator work they will pick what to merge and where, but doing changes falls under developer work. So when they change anything significant (not just typos in comments, whitespace and formatting), they will create a new submission with the reworked changes and post it for comments. So the original author or anybody else can point out any problems with the rework.
Note though that it still does not allow the original author to prohibit it on legal grounds, because they’ve already made the original contribution under license that permits modifying it. It does allow them to point out any technical (or aesthetic, but the maintainer is likely to stick to their taste anyway) reasons against the modification though.
1
On the first point, most open source maintainers go out of their way to give credit where credit is due. Not all version control systems make it easy or even possible to maintain separate author and committer fields, especially if multiple people worked on it. Be happy with the acknowledgement. Sometimes you might even get an extra surprise, like being listed as an author in the about dialog.
On the second point, maintainers deal with a lot of “fire and forget” contributors, who want to make one submission and move on. While some contributors prefer to own their code from start to finish, most are perfectly fine with letting someone else make tweaks for style issues and to address potential bugs they didn’t see due to lack of familiarity with the code. It is open source, after all, so it will get changed eventually, and it’s a lot easier to just make the change than to explain it and wait. If you’re the former type of contributor, you need to make that clear up front.