[DISCUSS] patch attribution

[Sean Busbey <bu...@apache.org>]

Hi folks!

Now that we're going to start getting patches into our own repository,
I'd like to discuss how we attribute authorship of patches from
non-committers. Personally, I've really liked the way things work for
git in the HBase community.

The commit author is set to the contributor (which is a different
piece of commit metadata than the one doing the committing). Then the
committer uses the git "signed-off-by" to include their name in the
commit message.

I really like this because as a community maintainer I can easily
parse the git history for information about contributions. (and check
it against similar data in jira)

What do other folks think?

-- 
Sean

Re: [DISCUSS] patch attribution

[Andrew Purtell <an...@gmail.com>]

+1

Also over in HBase, fwiw, if the contributor does not use format-patch to prepare something git am can handle, we apply the patch with the contributor's name in parenthesis after the jira identifier and title. 
 



> On Sep 22, 2015, at 9:19 PM, Sean Busbey <bu...@apache.org> wrote:
> 
> Hi folks!
> 
> Now that we're going to start getting patches into our own repository,
> I'd like to discuss how we attribute authorship of patches from
> non-committers. Personally, I've really liked the way things work for
> git in the HBase community.
> 
> The commit author is set to the contributor (which is a different
> piece of commit metadata than the one doing the committing). Then the
> committer uses the git "signed-off-by" to include their name in the
> commit message.
> 
> I really like this because as a community maintainer I can easily
> parse the git history for information about contributions. (and check
> it against similar data in jira)
> 
> What do other folks think?
> 
> -- 
> Sean

Re: [DISCUSS] patch attribution

[Sean Busbey <se...@gmail.com>]

On Sep 23, 2015 8:49 AM, "Alex Moundalexis" <al...@cloudera.com> wrote:
>
> +1
>
> Per Mark's note, instructions ought to be provided on how to generate
> patches in preferred format.
>
> Should also decide early whether to support PRs from GitHub and the plan
> for merging them, whether to allow GitHub to do the merge or whether to
> retrieve the patches and apply them.
>

I think I already turned on github integration, but I'll check this evening
to be sure.

What we can do with PRs is limited by the way the github <-> ASF
integration works. Essentially, PRs have to be merged by committers on the
CLI and can only be closed by the opener or a special phrase in the commit
message.

Re: [DISCUSS] patch attribution

[Alex Moundalexis <al...@cloudera.com>]

+1

Per Mark's note, instructions ought to be provided on how to generate
patches in preferred format.

Should also decide early whether to support PRs from GitHub and the plan
for merging them, whether to allow GitHub to do the merge or whether to
retrieve the patches and apply them.

On Wed, Sep 23, 2015 at 9:43 AM, Bill Havanki <bh...@apache.org> wrote:

> +1
>
> (Hi everyone!)
>
> When it comes time to selecting someone as a committer, I'm sure it'd much
> easier if their contributions were easily locatable vs. masked by the
> various people who happened to commit them. Also, credit where credit is
> due.
>
> On Wed, Sep 23, 2015 at 12:58 AM, Mark Grover <ma...@apache.org> wrote:
>
> > +1
> > We use the same in Apache Bigtop and I really like it as well. We request
> > contributors to create the patch by 'git format-patch' which the
> committer
> > can then 'sign-off and commit'. FYI, Bigtop's instructions are listed
> here
> > <
> >
> https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute#HowtoContribute-Howtogeneratepatches
> > >
> > .
> >
> > On Tue, Sep 22, 2015 at 9:19 PM, Sean Busbey <bu...@apache.org> wrote:
> >
> > > Hi folks!
> > >
> > > Now that we're going to start getting patches into our own repository,
> > > I'd like to discuss how we attribute authorship of patches from
> > > non-committers. Personally, I've really liked the way things work for
> > > git in the HBase community.
> > >
> > > The commit author is set to the contributor (which is a different
> > > piece of commit metadata than the one doing the committing). Then the
> > > committer uses the git "signed-off-by" to include their name in the
> > > commit message.
> > >
> > > I really like this because as a community maintainer I can easily
> > > parse the git history for information about contributions. (and check
> > > it against similar data in jira)
> > >
> > > What do other folks think?
> > >
> > > --
> > > Sean
> > >
> >
>



-- 
Alex Moundalexis
@technmsg

Re: [DISCUSS] patch attribution

[Bill Havanki <bh...@apache.org>]

+1

(Hi everyone!)

When it comes time to selecting someone as a committer, I'm sure it'd much
easier if their contributions were easily locatable vs. masked by the
various people who happened to commit them. Also, credit where credit is
due.

On Wed, Sep 23, 2015 at 12:58 AM, Mark Grover <ma...@apache.org> wrote:

> +1
> We use the same in Apache Bigtop and I really like it as well. We request
> contributors to create the patch by 'git format-patch' which the committer
> can then 'sign-off and commit'. FYI, Bigtop's instructions are listed here
> <
> https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute#HowtoContribute-Howtogeneratepatches
> >
> .
>
> On Tue, Sep 22, 2015 at 9:19 PM, Sean Busbey <bu...@apache.org> wrote:
>
> > Hi folks!
> >
> > Now that we're going to start getting patches into our own repository,
> > I'd like to discuss how we attribute authorship of patches from
> > non-committers. Personally, I've really liked the way things work for
> > git in the HBase community.
> >
> > The commit author is set to the contributor (which is a different
> > piece of commit metadata than the one doing the committing). Then the
> > committer uses the git "signed-off-by" to include their name in the
> > commit message.
> >
> > I really like this because as a community maintainer I can easily
> > parse the git history for information about contributions. (and check
> > it against similar data in jira)
> >
> > What do other folks think?
> >
> > --
> > Sean
> >
>

Re: [DISCUSS] patch attribution

[Mark Grover <ma...@apache.org>]

+1
We use the same in Apache Bigtop and I really like it as well. We request
contributors to create the patch by 'git format-patch' which the committer
can then 'sign-off and commit'. FYI, Bigtop's instructions are listed here
<https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute#HowtoContribute-Howtogeneratepatches>
.

On Tue, Sep 22, 2015 at 9:19 PM, Sean Busbey <bu...@apache.org> wrote:

> Hi folks!
>
> Now that we're going to start getting patches into our own repository,
> I'd like to discuss how we attribute authorship of patches from
> non-committers. Personally, I've really liked the way things work for
> git in the HBase community.
>
> The commit author is set to the contributor (which is a different
> piece of commit metadata than the one doing the committing). Then the
> committer uses the git "signed-off-by" to include their name in the
> commit message.
>
> I really like this because as a community maintainer I can easily
> parse the git history for information about contributions. (and check
> it against similar data in jira)
>
> What do other folks think?
>
> --
> Sean
>

Re: [DISCUSS] patch attribution

[Sean Busbey <bu...@apache.org>]

Yep Anu, that's exactly correct.


On Tue, Sep 29, 2015 at 12:56 PM, Anu Engineer
<ae...@hortonworks.com> wrote:
> Does this mean that I can send a patch using git workflow as opposed to creating patch files.
>
>> assuming that I am on my own branch
> git format-patch trunk —stdout  > YETUS-001.patch
>
>>And you can apply with
> git am —signoff < YETUS-001.patch
>
> That way the committer does not have to write anything like committer or signed-off by since the patch file has a metadata of the author and git applies the correct values.
> Just making sure that this is indeed what Sean refers to in his email.
>
> Thanks
> Anu
>
>
>
>
> On 9/29/15, 10:37 AM, "Chris Nauroth" <cn...@hortonworks.com> wrote:
>
>>+1
>>
>>I haven't worked this way before, but I like it!  It sounds like we still
>>maintain 2 important pieces of metadata: contributor and
>>signoff/committer.  I consider the latter important, because it helps me
>>identify which committers are really actively doing reviews right now, in
>>case I need to request a review directly.
>>
>>--Chris Nauroth
>>
>>
>>
>>
>>On 9/22/15, 9:19 PM, "Sean Busbey" <bu...@apache.org> wrote:
>>
>>>Hi folks!
>>>
>>>Now that we're going to start getting patches into our own repository,
>>>I'd like to discuss how we attribute authorship of patches from
>>>non-committers. Personally, I've really liked the way things work for
>>>git in the HBase community.
>>>
>>>The commit author is set to the contributor (which is a different
>>>piece of commit metadata than the one doing the committing). Then the
>>>committer uses the git "signed-off-by" to include their name in the
>>>commit message.
>>>
>>>I really like this because as a community maintainer I can easily
>>>parse the git history for information about contributions. (and check
>>>it against similar data in jira)
>>>
>>>What do other folks think?
>>>
>>>--
>>>Sean
>>>
>>
>>

Re: [DISCUSS] patch attribution

[Anu Engineer <ae...@hortonworks.com>]

Does this mean that I can send a patch using git workflow as opposed to creating patch files.

> assuming that I am on my own branch 
git format-patch trunk —stdout  > YETUS-001.patch

>And you can apply with 
git am —signoff < YETUS-001.patch

That way the committer does not have to write anything like committer or signed-off by since the patch file has a metadata of the author and git applies the correct values.
Just making sure that this is indeed what Sean refers to in his email.

Thanks
Anu




On 9/29/15, 10:37 AM, "Chris Nauroth" <cn...@hortonworks.com> wrote:

>+1
>
>I haven't worked this way before, but I like it!  It sounds like we still
>maintain 2 important pieces of metadata: contributor and
>signoff/committer.  I consider the latter important, because it helps me
>identify which committers are really actively doing reviews right now, in
>case I need to request a review directly.
>
>--Chris Nauroth
>
>
>
>
>On 9/22/15, 9:19 PM, "Sean Busbey" <bu...@apache.org> wrote:
>
>>Hi folks!
>>
>>Now that we're going to start getting patches into our own repository,
>>I'd like to discuss how we attribute authorship of patches from
>>non-committers. Personally, I've really liked the way things work for
>>git in the HBase community.
>>
>>The commit author is set to the contributor (which is a different
>>piece of commit metadata than the one doing the committing). Then the
>>committer uses the git "signed-off-by" to include their name in the
>>commit message.
>>
>>I really like this because as a community maintainer I can easily
>>parse the git history for information about contributions. (and check
>>it against similar data in jira)
>>
>>What do other folks think?
>>
>>-- 
>>Sean
>>
>
>

Re: [DISCUSS] patch attribution

[Chris Nauroth <cn...@hortonworks.com>]

+1

I haven't worked this way before, but I like it!  It sounds like we still
maintain 2 important pieces of metadata: contributor and
signoff/committer.  I consider the latter important, because it helps me
identify which committers are really actively doing reviews right now, in
case I need to request a review directly.

--Chris Nauroth




On 9/22/15, 9:19 PM, "Sean Busbey" <bu...@apache.org> wrote:

>Hi folks!
>
>Now that we're going to start getting patches into our own repository,
>I'd like to discuss how we attribute authorship of patches from
>non-committers. Personally, I've really liked the way things work for
>git in the HBase community.
>
>The commit author is set to the contributor (which is a different
>piece of commit metadata than the one doing the committing). Then the
>committer uses the git "signed-off-by" to include their name in the
>commit message.
>
>I really like this because as a community maintainer I can easily
>parse the git history for information about contributions. (and check
>it against similar data in jira)
>
>What do other folks think?
>
>-- 
>Sean
>