Sean, My goal was to ensure the original author's contribution is captured on the commit, rather than in the jira "assigned to" field.
A few scenarios: Scenario #1 A contributor submits a pr for a jira issue. It requires no modifications and can be merged into master (e.g. https://github.com/apache/nifi/pull/106, https://issues.apache.org/jira/browse/NIFI-1046) Here, I modify the commit messages to indicate I've reviewed, usually with git commit --amend, but here I squashed and modified the commit messages (and note the close of the issue on github). Retains the author email in the commit message. While I did this it was assigned to me on jira and closed as me. Scenario #2 A contributor submits a pr on a jira issue. It requires very minor modifications and can be merged into master (e.g. https://github.com/apache/nifi/pull/105, https://issues.apache.org/jira/browse/NIFI-1042) Here, I merged and squashed the commits (including my slight modification), ensured the commit message retained the author include a review message and closed the pr. While I did this it was assigned to me on jira and closed as me. Scenario #3 A contributor submits a pr for a jira issue. It requires some amendments which might make slight changes. (e.g. https://github.com/apache/nifi/pull/88, https://issues.apache.org/jira/browse/NIFI-945) Here I rebased and made some style modifications which I had the original author review. I ensured the commit message retained the author include a review message and closed the pr. I also added a note that I made amendments. While I did this it was assigned to me on jira and closed as me. Scenario #4 A contributor submits a pr for a jira issue. It requires some heavy amendments, because as I'm reviewing I find a bug in testing, and while diagnosing I basically develop a patch myself. (e.g. https://github.com/apache/nifi/pull/104, https://issues.apache.org/jira/browse/NIFI-747) I apply a patch. While testing, it doesn't quite work. I'm trying to diagnose so I can give feedback on the PR and while doing so, develop a fix. In this case, I pushed my branch and Joe reviewed it. After the review, I merged it in. In this case, I commented in the commit message the original author, but left myself as the author. While I did this it was assigned to me on jira and closed as me. I borrowed heavily from what Aldrin was doing. Consistency would be good, I noticed other "styles" like this, which is more of a functional log. https://github.com/apache/nifi/commit/da28b81eece1277c7500f28708155239ae317e57 On Wed, Oct 21, 2015 at 12:19 PM, Tony Kurc <[email protected]> wrote: > > That would be wonderful. Would you be fine if I rolled the info up into > > a PMC guide? > > Yes, I'll pull together some examples tonight > > On Tue, Oct 20, 2015 at 4:54 PM, Sean Busbey <[email protected]> wrote: > >> well that's frustrating. >> >> It was approximately: >> >> [1]: The use of ammending-author started as a way of handling >> gnarly cherry-picks back to earlier release lines in HBase, but >> I've seen it show up on a couple of multiple-author patches >> generally. >> >> The HBase reference guide is 404 at the moment, so the best >> link I can find is the mailing list thread the explanation references: >> >> http://search-hadoop.com/m/DHED4wHGYS >> >> >> >> On Tue, Oct 20, 2015 at 3:46 PM, Tony Kurc <[email protected]> wrote: >> > Sean, >> > I think your footnote link got chopped. >> > >> > Tony >> > >> > On Tue, Oct 20, 2015 at 4:39 PM, Sean Busbey <[email protected]> >> wrote: >> > >> >> Well, I admit that my questions were as much to get more questions as >> >> to advance an idea of answers. :) >> >> >> >> >> >> On Tue, Oct 20, 2015 at 3:16 PM, Tony Kurc <[email protected]> wrote: >> >> > Sean, >> >> > Can you better define "completed by a non-committer"? >> >> > >> >> >> >> Where the majority of the work is done by a non-commiter. I'd even err >> >> this on the side of "any substantial", but that's largely because I >> try to >> >> err >> >> on the side of encouraging new people with visible credit. >> >> >> >> >> >> > Some cases to consider >> >> > Is "a jira" complete when a patch is submitted or when it is merged >> into >> >> > the code repository? >> >> >> >> definitely when all work is complete, and for things that involve >> patches >> >> to the code base, that would mean merged (either into a release line >> >> or into a feature branch if the jira is a part of a mutli-jira effort >> with >> >> such >> >> a feature branch). >> >> >> >> >> >> > If a patch requires a bit of work to integrate (and test), where does >> >> that >> >> > fall? >> >> >> >> In other projects I usually cover this with the commit's >> "signed-off-by". >> >> if >> >> there's a substantial amount of changes involved then an additional >> >> "ammending-author" tag per extra contributor (e.g. hbase does this >> >> as policy[1]). Figuring out when the tag is needed is largely a >> judgement >> >> call AFAICT. >> >> >> >> In both of those cases, I'd personally prefer the jira go to whomever >> did >> >> the bulk of the work. 'did the bulk of the work' could be the original >> >> author or the >> >> integrator depending on jira phrasing, e.g. 'incorporate this external >> >> work' is different from a patch that is 80% done by an initial >> contributor >> >> but finished by another. >> >> >> >> I've definitely seen projects take the other substantially less >> ambiguous >> >> approach. Apache Curator, for example, assigns jiras to whatever >> >> committer handled the merge. >> >> >> >> > What if a patch provider doesn't have a jira account? >> >> >> >> How would we track provenance of the contribution / grant to the ASF? >> >> I guess by git information? At the risk of derailing this thread, is >> git >> >> how we're doing this now? >> >> >> >> > What if integrating a patch a substantial rewrite of the patch? >> >> >> >> I'd usually push back on the contributor to do the rewrite in most >> cases >> >> and use "amending-author" in git as described above for either the >> >> original or amending author. >> >> >> >> >> >> > >> >> > I can certainly tell you what I did based on my ability to >> "introspect" >> >> our >> >> > team conventions from jira, commit log and mailing list in lieu of a >> >> > documented committer guide. >> >> > >> >> >> >> That would be wonderful. Would you be fine if I rolled the info up into >> >> a PMC guide? >> >> >> >> -- >> >> Sean >> >> >> >> >> >> -- >> Sean >> > >
