> 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 >
