Re: Advice on policy merging non-committer branches

[Noah Slater <ns...@tumbolia.org>]

Paul, can you document this somewhere? It looks like a great candidate for
our Git proposal to the ASF.

On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <pa...@gmail.com>wrote:

> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jh...@apache.org> wrote:
> > I would like to merge a branch from a non-committer[1]. The log shows
> > a non-apache author, but an apache committer.
> >
> > What is the policy regarding this? I was thinking the following:
> >
> > 1. Merge freely and promiscuously from anybody in my GitHub (or
> > whatever) repo (community engagement)
>
> Not quite. More below.
>
> > 2. As the branch nears time for "promotion," ask the non-committer to
> > git format-patch and attach to JIRA, signing (checking) the license
> > transfer.
>
> Unnecessary.
>
> > 3. With that settled, either git rebase or `git am` (I'm unclear about
> > this). The point is, get an @apache.org committer id on each commit.
>
> Unnecessary.
>
> > 4. Push where appropriate into the ASF repo
> >
>
> Included in discussion of 1 below.
>
> > Questions:
> >
> > Must the non-committer attach the exact same commit id? Or is it
> > sufficient that it merely be the same diff (delta)? (I changed the ID
> > when I rebased his commit and added my email to the committer header.)
> >
>
> No. Commit SHA's are in no way important from a license perspective.
>
> > Before the JIRA license agreement, may we push non-committers' code to
> > the repo at all?
> >
>
> Kinda, see below.
>
> > Before the JIRA license agreement, may we push non-committers' code to
> > the more official branches: master, 1.2.x, etc.?
> >
> > May we push whatever we want so long as the license agreement is
> > signed (checked) before voting on a release artifact?
>
> For the last two questions, definitely not. Never push code to ASF
> hardware that you're not 100% certain is OK to be in the repository.
> That doesn't necessarily mean that it has to have the ASF license
> attached, but if you don't know that it can be in the repo, don't push
> it.
>
> First things first, as a committer you have to remember the ICLA that
> you signed. Its your responsibility to make sure that all code you
> push to the repository is compliant with ASF policies and the legal
> aspects those entails.
>
> Before Git, the general policy we used in CouchDB was to request that
> non-trivial patches be submitted to JIRA and have people click the
> checkbox. While this captures the general intent of things, it has
> been declared an official position of the board that this is
> unnecessary for accepting contributions. It has also been decided that
> the committer and author fields do not have to be tied to specific
> Apache accounts.
>
> The policy as it stands now is that we must be able to demonstrate
> that there was a clear intent for the code in question to be
> contributed. While there hasn't been an official position on how to
> demonstrate intent I think there are a couple things that are fairly
> obvious:
>
> Traditional:
>
> 1. Same as always: Anything submitted to JIRA. The check box has been
> declared not a necessity though I think the input field is required,
> and if someone said "not-intended for inclusion" we should just
> clarify if that was an accident or not.
>
> 2. Patches submitted to a mailing list.
>
> New with Git:
>
> 3. If someone posts a link to a publicly available Git branch with
> language indicating their intent for it to be included, then we should
> feel free to add the repo as a remote and yank it in. While not
> absolutely necessary, it might be a good idea to rewrite the commit
> message to reference either the email or the original contributed
> commit sha (in case of a rebase) so that we can link the two.
>
> 4. Jukka Zitting has recently been doing work on connecting GitHub
> Pull Requests to the dev@ mailing lists. Assuming this is the case I
> think we should feel free to take any code submitted in this manner.
> Thus our old "Submit that to JIRA" would be a "Send us a Pull
> Request".
>
> In contrast, we shouldn't feel free to just find code in a random
> GitHub fork and push that onto ASF hardware. If there's something we
> see that we want then we should ask for clarification (plus that's
> only polite).
>
> Bottom line, as a committer you're responsible for the code that you
> push to the repository. If you're not sure on a specific patch or
> situation, bring it up to dev@ or similar venue and we can run it up
> the flag pole until we find an answer.
>

Re: Advice on policy merging non-committer branches

[Paul Davis <pa...@gmail.com>]

*Our* Git proposal. But yeah. I have it referenced for when we sit
down and put that report together.

On Sat, Mar 3, 2012 at 8:48 PM, Noah Slater <ns...@tumbolia.org> wrote:
> You know, after I sent that, I thought to myself, "I bet Paul will send
> some sarcastic remark about how the mailing list counts as documentation."
> Then I thought better of it, and didn't respond. Of course, what I really
> meant, is that it would be cool if you repurposed what you already wrote
> for the wiki, or merged it in to the current draft of our Git proposal.
>
> On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <pa...@gmail.com>wrote:
>
>> Noah,
>>
>> Sure, let me write that up and send it in an email to dev@.
>>
>> Paul
>>
>> On Sat, Mar 3, 2012 at 7:33 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> > Paul, can you document this somewhere? It looks like a great candidate
>> for
>> > our Git proposal to the ASF.
>> >
>> > On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <paul.joseph.davis@gmail.com
>> >wrote:
>> >
>> >> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jh...@apache.org> wrote:
>> >> > I would like to merge a branch from a non-committer[1]. The log shows
>> >> > a non-apache author, but an apache committer.
>> >> >
>> >> > What is the policy regarding this? I was thinking the following:
>> >> >
>> >> > 1. Merge freely and promiscuously from anybody in my GitHub (or
>> >> > whatever) repo (community engagement)
>> >>
>> >> Not quite. More below.
>> >>
>> >> > 2. As the branch nears time for "promotion," ask the non-committer to
>> >> > git format-patch and attach to JIRA, signing (checking) the license
>> >> > transfer.
>> >>
>> >> Unnecessary.
>> >>
>> >> > 3. With that settled, either git rebase or `git am` (I'm unclear about
>> >> > this). The point is, get an @apache.org committer id on each commit.
>> >>
>> >> Unnecessary.
>> >>
>> >> > 4. Push where appropriate into the ASF repo
>> >> >
>> >>
>> >> Included in discussion of 1 below.
>> >>
>> >> > Questions:
>> >> >
>> >> > Must the non-committer attach the exact same commit id? Or is it
>> >> > sufficient that it merely be the same diff (delta)? (I changed the ID
>> >> > when I rebased his commit and added my email to the committer header.)
>> >> >
>> >>
>> >> No. Commit SHA's are in no way important from a license perspective.
>> >>
>> >> > Before the JIRA license agreement, may we push non-committers' code to
>> >> > the repo at all?
>> >> >
>> >>
>> >> Kinda, see below.
>> >>
>> >> > Before the JIRA license agreement, may we push non-committers' code to
>> >> > the more official branches: master, 1.2.x, etc.?
>> >> >
>> >> > May we push whatever we want so long as the license agreement is
>> >> > signed (checked) before voting on a release artifact?
>> >>
>> >> For the last two questions, definitely not. Never push code to ASF
>> >> hardware that you're not 100% certain is OK to be in the repository.
>> >> That doesn't necessarily mean that it has to have the ASF license
>> >> attached, but if you don't know that it can be in the repo, don't push
>> >> it.
>> >>
>> >> First things first, as a committer you have to remember the ICLA that
>> >> you signed. Its your responsibility to make sure that all code you
>> >> push to the repository is compliant with ASF policies and the legal
>> >> aspects those entails.
>> >>
>> >> Before Git, the general policy we used in CouchDB was to request that
>> >> non-trivial patches be submitted to JIRA and have people click the
>> >> checkbox. While this captures the general intent of things, it has
>> >> been declared an official position of the board that this is
>> >> unnecessary for accepting contributions. It has also been decided that
>> >> the committer and author fields do not have to be tied to specific
>> >> Apache accounts.
>> >>
>> >> The policy as it stands now is that we must be able to demonstrate
>> >> that there was a clear intent for the code in question to be
>> >> contributed. While there hasn't been an official position on how to
>> >> demonstrate intent I think there are a couple things that are fairly
>> >> obvious:
>> >>
>> >> Traditional:
>> >>
>> >> 1. Same as always: Anything submitted to JIRA. The check box has been
>> >> declared not a necessity though I think the input field is required,
>> >> and if someone said "not-intended for inclusion" we should just
>> >> clarify if that was an accident or not.
>> >>
>> >> 2. Patches submitted to a mailing list.
>> >>
>> >> New with Git:
>> >>
>> >> 3. If someone posts a link to a publicly available Git branch with
>> >> language indicating their intent for it to be included, then we should
>> >> feel free to add the repo as a remote and yank it in. While not
>> >> absolutely necessary, it might be a good idea to rewrite the commit
>> >> message to reference either the email or the original contributed
>> >> commit sha (in case of a rebase) so that we can link the two.
>> >>
>> >> 4. Jukka Zitting has recently been doing work on connecting GitHub
>> >> Pull Requests to the dev@ mailing lists. Assuming this is the case I
>> >> think we should feel free to take any code submitted in this manner.
>> >> Thus our old "Submit that to JIRA" would be a "Send us a Pull
>> >> Request".
>> >>
>> >> In contrast, we shouldn't feel free to just find code in a random
>> >> GitHub fork and push that onto ASF hardware. If there's something we
>> >> see that we want then we should ask for clarification (plus that's
>> >> only polite).
>> >>
>> >> Bottom line, as a committer you're responsible for the code that you
>> >> push to the repository. If you're not sure on a specific patch or
>> >> situation, bring it up to dev@ or similar venue and we can run it up
>> >> the flag pole until we find an answer.
>> >>
>>

Re: Advice on policy merging non-committer branches

[Noah Slater <ns...@tumbolia.org>]

You know, after I sent that, I thought to myself, "I bet Paul will send
some sarcastic remark about how the mailing list counts as documentation."
Then I thought better of it, and didn't respond. Of course, what I really
meant, is that it would be cool if you repurposed what you already wrote
for the wiki, or merged it in to the current draft of our Git proposal.

On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <pa...@gmail.com>wrote:

> Noah,
>
> Sure, let me write that up and send it in an email to dev@.
>
> Paul
>
> On Sat, Mar 3, 2012 at 7:33 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Paul, can you document this somewhere? It looks like a great candidate
> for
> > our Git proposal to the ASF.
> >
> > On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <paul.joseph.davis@gmail.com
> >wrote:
> >
> >> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jh...@apache.org> wrote:
> >> > I would like to merge a branch from a non-committer[1]. The log shows
> >> > a non-apache author, but an apache committer.
> >> >
> >> > What is the policy regarding this? I was thinking the following:
> >> >
> >> > 1. Merge freely and promiscuously from anybody in my GitHub (or
> >> > whatever) repo (community engagement)
> >>
> >> Not quite. More below.
> >>
> >> > 2. As the branch nears time for "promotion," ask the non-committer to
> >> > git format-patch and attach to JIRA, signing (checking) the license
> >> > transfer.
> >>
> >> Unnecessary.
> >>
> >> > 3. With that settled, either git rebase or `git am` (I'm unclear about
> >> > this). The point is, get an @apache.org committer id on each commit.
> >>
> >> Unnecessary.
> >>
> >> > 4. Push where appropriate into the ASF repo
> >> >
> >>
> >> Included in discussion of 1 below.
> >>
> >> > Questions:
> >> >
> >> > Must the non-committer attach the exact same commit id? Or is it
> >> > sufficient that it merely be the same diff (delta)? (I changed the ID
> >> > when I rebased his commit and added my email to the committer header.)
> >> >
> >>
> >> No. Commit SHA's are in no way important from a license perspective.
> >>
> >> > Before the JIRA license agreement, may we push non-committers' code to
> >> > the repo at all?
> >> >
> >>
> >> Kinda, see below.
> >>
> >> > Before the JIRA license agreement, may we push non-committers' code to
> >> > the more official branches: master, 1.2.x, etc.?
> >> >
> >> > May we push whatever we want so long as the license agreement is
> >> > signed (checked) before voting on a release artifact?
> >>
> >> For the last two questions, definitely not. Never push code to ASF
> >> hardware that you're not 100% certain is OK to be in the repository.
> >> That doesn't necessarily mean that it has to have the ASF license
> >> attached, but if you don't know that it can be in the repo, don't push
> >> it.
> >>
> >> First things first, as a committer you have to remember the ICLA that
> >> you signed. Its your responsibility to make sure that all code you
> >> push to the repository is compliant with ASF policies and the legal
> >> aspects those entails.
> >>
> >> Before Git, the general policy we used in CouchDB was to request that
> >> non-trivial patches be submitted to JIRA and have people click the
> >> checkbox. While this captures the general intent of things, it has
> >> been declared an official position of the board that this is
> >> unnecessary for accepting contributions. It has also been decided that
> >> the committer and author fields do not have to be tied to specific
> >> Apache accounts.
> >>
> >> The policy as it stands now is that we must be able to demonstrate
> >> that there was a clear intent for the code in question to be
> >> contributed. While there hasn't been an official position on how to
> >> demonstrate intent I think there are a couple things that are fairly
> >> obvious:
> >>
> >> Traditional:
> >>
> >> 1. Same as always: Anything submitted to JIRA. The check box has been
> >> declared not a necessity though I think the input field is required,
> >> and if someone said "not-intended for inclusion" we should just
> >> clarify if that was an accident or not.
> >>
> >> 2. Patches submitted to a mailing list.
> >>
> >> New with Git:
> >>
> >> 3. If someone posts a link to a publicly available Git branch with
> >> language indicating their intent for it to be included, then we should
> >> feel free to add the repo as a remote and yank it in. While not
> >> absolutely necessary, it might be a good idea to rewrite the commit
> >> message to reference either the email or the original contributed
> >> commit sha (in case of a rebase) so that we can link the two.
> >>
> >> 4. Jukka Zitting has recently been doing work on connecting GitHub
> >> Pull Requests to the dev@ mailing lists. Assuming this is the case I
> >> think we should feel free to take any code submitted in this manner.
> >> Thus our old "Submit that to JIRA" would be a "Send us a Pull
> >> Request".
> >>
> >> In contrast, we shouldn't feel free to just find code in a random
> >> GitHub fork and push that onto ASF hardware. If there's something we
> >> see that we want then we should ask for clarification (plus that's
> >> only polite).
> >>
> >> Bottom line, as a committer you're responsible for the code that you
> >> push to the repository. If you're not sure on a specific patch or
> >> situation, bring it up to dev@ or similar venue and we can run it up
> >> the flag pole until we find an answer.
> >>
>

Re: Advice on policy merging non-committer branches

[Noah Slater <ns...@tumbolia.org>]

Thanks Jason!

On Sun, Mar 4, 2012 at 9:35 AM, Jason Smith <jh...@iriscouch.com> wrote:

> Converted to a wiki page: http://wiki.apache.org/couchdb/CommitPolicy
>
> On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <pa...@gmail.com>
> wrote:
> > Noah,
> >
> > Sure, let me write that up and send it in an email to dev@.
> >
> > Paul
> >
> > On Sat, Mar 3, 2012 at 7:33 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >> Paul, can you document this somewhere? It looks like a great candidate
> for
> >> our Git proposal to the ASF.
> >>
> >> On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <
> paul.joseph.davis@gmail.com>wrote:
> >>
> >>> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jh...@apache.org> wrote:
> >>> > I would like to merge a branch from a non-committer[1]. The log shows
> >>> > a non-apache author, but an apache committer.
> >>> >
> >>> > What is the policy regarding this? I was thinking the following:
> >>> >
> >>> > 1. Merge freely and promiscuously from anybody in my GitHub (or
> >>> > whatever) repo (community engagement)
> >>>
> >>> Not quite. More below.
> >>>
> >>> > 2. As the branch nears time for "promotion," ask the non-committer to
> >>> > git format-patch and attach to JIRA, signing (checking) the license
> >>> > transfer.
> >>>
> >>> Unnecessary.
> >>>
> >>> > 3. With that settled, either git rebase or `git am` (I'm unclear
> about
> >>> > this). The point is, get an @apache.org committer id on each commit.
> >>>
> >>> Unnecessary.
> >>>
> >>> > 4. Push where appropriate into the ASF repo
> >>> >
> >>>
> >>> Included in discussion of 1 below.
> >>>
> >>> > Questions:
> >>> >
> >>> > Must the non-committer attach the exact same commit id? Or is it
> >>> > sufficient that it merely be the same diff (delta)? (I changed the ID
> >>> > when I rebased his commit and added my email to the committer
> header.)
> >>> >
> >>>
> >>> No. Commit SHA's are in no way important from a license perspective.
> >>>
> >>> > Before the JIRA license agreement, may we push non-committers' code
> to
> >>> > the repo at all?
> >>> >
> >>>
> >>> Kinda, see below.
> >>>
> >>> > Before the JIRA license agreement, may we push non-committers' code
> to
> >>> > the more official branches: master, 1.2.x, etc.?
> >>> >
> >>> > May we push whatever we want so long as the license agreement is
> >>> > signed (checked) before voting on a release artifact?
> >>>
> >>> For the last two questions, definitely not. Never push code to ASF
> >>> hardware that you're not 100% certain is OK to be in the repository.
> >>> That doesn't necessarily mean that it has to have the ASF license
> >>> attached, but if you don't know that it can be in the repo, don't push
> >>> it.
> >>>
> >>> First things first, as a committer you have to remember the ICLA that
> >>> you signed. Its your responsibility to make sure that all code you
> >>> push to the repository is compliant with ASF policies and the legal
> >>> aspects those entails.
> >>>
> >>> Before Git, the general policy we used in CouchDB was to request that
> >>> non-trivial patches be submitted to JIRA and have people click the
> >>> checkbox. While this captures the general intent of things, it has
> >>> been declared an official position of the board that this is
> >>> unnecessary for accepting contributions. It has also been decided that
> >>> the committer and author fields do not have to be tied to specific
> >>> Apache accounts.
> >>>
> >>> The policy as it stands now is that we must be able to demonstrate
> >>> that there was a clear intent for the code in question to be
> >>> contributed. While there hasn't been an official position on how to
> >>> demonstrate intent I think there are a couple things that are fairly
> >>> obvious:
> >>>
> >>> Traditional:
> >>>
> >>> 1. Same as always: Anything submitted to JIRA. The check box has been
> >>> declared not a necessity though I think the input field is required,
> >>> and if someone said "not-intended for inclusion" we should just
> >>> clarify if that was an accident or not.
> >>>
> >>> 2. Patches submitted to a mailing list.
> >>>
> >>> New with Git:
> >>>
> >>> 3. If someone posts a link to a publicly available Git branch with
> >>> language indicating their intent for it to be included, then we should
> >>> feel free to add the repo as a remote and yank it in. While not
> >>> absolutely necessary, it might be a good idea to rewrite the commit
> >>> message to reference either the email or the original contributed
> >>> commit sha (in case of a rebase) so that we can link the two.
> >>>
> >>> 4. Jukka Zitting has recently been doing work on connecting GitHub
> >>> Pull Requests to the dev@ mailing lists. Assuming this is the case I
> >>> think we should feel free to take any code submitted in this manner.
> >>> Thus our old "Submit that to JIRA" would be a "Send us a Pull
> >>> Request".
> >>>
> >>> In contrast, we shouldn't feel free to just find code in a random
> >>> GitHub fork and push that onto ASF hardware. If there's something we
> >>> see that we want then we should ask for clarification (plus that's
> >>> only polite).
> >>>
> >>> Bottom line, as a committer you're responsible for the code that you
> >>> push to the repository. If you're not sure on a specific patch or
> >>> situation, bring it up to dev@ or similar venue and we can run it up
> >>> the flag pole until we find an answer.
> >>>
>
>
>
> --
> Iris Couch
>

Re: Advice on policy merging non-committer branches

[Jason Smith <jh...@iriscouch.com>]

Converted to a wiki page: http://wiki.apache.org/couchdb/CommitPolicy

On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <pa...@gmail.com> wrote:
> Noah,
>
> Sure, let me write that up and send it in an email to dev@.
>
> Paul
>
> On Sat, Mar 3, 2012 at 7:33 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> Paul, can you document this somewhere? It looks like a great candidate for
>> our Git proposal to the ASF.
>>
>> On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <pa...@gmail.com>wrote:
>>
>>> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jh...@apache.org> wrote:
>>> > I would like to merge a branch from a non-committer[1]. The log shows
>>> > a non-apache author, but an apache committer.
>>> >
>>> > What is the policy regarding this? I was thinking the following:
>>> >
>>> > 1. Merge freely and promiscuously from anybody in my GitHub (or
>>> > whatever) repo (community engagement)
>>>
>>> Not quite. More below.
>>>
>>> > 2. As the branch nears time for "promotion," ask the non-committer to
>>> > git format-patch and attach to JIRA, signing (checking) the license
>>> > transfer.
>>>
>>> Unnecessary.
>>>
>>> > 3. With that settled, either git rebase or `git am` (I'm unclear about
>>> > this). The point is, get an @apache.org committer id on each commit.
>>>
>>> Unnecessary.
>>>
>>> > 4. Push where appropriate into the ASF repo
>>> >
>>>
>>> Included in discussion of 1 below.
>>>
>>> > Questions:
>>> >
>>> > Must the non-committer attach the exact same commit id? Or is it
>>> > sufficient that it merely be the same diff (delta)? (I changed the ID
>>> > when I rebased his commit and added my email to the committer header.)
>>> >
>>>
>>> No. Commit SHA's are in no way important from a license perspective.
>>>
>>> > Before the JIRA license agreement, may we push non-committers' code to
>>> > the repo at all?
>>> >
>>>
>>> Kinda, see below.
>>>
>>> > Before the JIRA license agreement, may we push non-committers' code to
>>> > the more official branches: master, 1.2.x, etc.?
>>> >
>>> > May we push whatever we want so long as the license agreement is
>>> > signed (checked) before voting on a release artifact?
>>>
>>> For the last two questions, definitely not. Never push code to ASF
>>> hardware that you're not 100% certain is OK to be in the repository.
>>> That doesn't necessarily mean that it has to have the ASF license
>>> attached, but if you don't know that it can be in the repo, don't push
>>> it.
>>>
>>> First things first, as a committer you have to remember the ICLA that
>>> you signed. Its your responsibility to make sure that all code you
>>> push to the repository is compliant with ASF policies and the legal
>>> aspects those entails.
>>>
>>> Before Git, the general policy we used in CouchDB was to request that
>>> non-trivial patches be submitted to JIRA and have people click the
>>> checkbox. While this captures the general intent of things, it has
>>> been declared an official position of the board that this is
>>> unnecessary for accepting contributions. It has also been decided that
>>> the committer and author fields do not have to be tied to specific
>>> Apache accounts.
>>>
>>> The policy as it stands now is that we must be able to demonstrate
>>> that there was a clear intent for the code in question to be
>>> contributed. While there hasn't been an official position on how to
>>> demonstrate intent I think there are a couple things that are fairly
>>> obvious:
>>>
>>> Traditional:
>>>
>>> 1. Same as always: Anything submitted to JIRA. The check box has been
>>> declared not a necessity though I think the input field is required,
>>> and if someone said "not-intended for inclusion" we should just
>>> clarify if that was an accident or not.
>>>
>>> 2. Patches submitted to a mailing list.
>>>
>>> New with Git:
>>>
>>> 3. If someone posts a link to a publicly available Git branch with
>>> language indicating their intent for it to be included, then we should
>>> feel free to add the repo as a remote and yank it in. While not
>>> absolutely necessary, it might be a good idea to rewrite the commit
>>> message to reference either the email or the original contributed
>>> commit sha (in case of a rebase) so that we can link the two.
>>>
>>> 4. Jukka Zitting has recently been doing work on connecting GitHub
>>> Pull Requests to the dev@ mailing lists. Assuming this is the case I
>>> think we should feel free to take any code submitted in this manner.
>>> Thus our old "Submit that to JIRA" would be a "Send us a Pull
>>> Request".
>>>
>>> In contrast, we shouldn't feel free to just find code in a random
>>> GitHub fork and push that onto ASF hardware. If there's something we
>>> see that we want then we should ask for clarification (plus that's
>>> only polite).
>>>
>>> Bottom line, as a committer you're responsible for the code that you
>>> push to the repository. If you're not sure on a specific patch or
>>> situation, bring it up to dev@ or similar venue and we can run it up
>>> the flag pole until we find an answer.
>>>



-- 
Iris Couch

Re: Advice on policy merging non-committer branches

[Paul Davis <pa...@gmail.com>]

Noah,

Sure, let me write that up and send it in an email to dev@.

Paul

On Sat, Mar 3, 2012 at 7:33 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Paul, can you document this somewhere? It looks like a great candidate for
> our Git proposal to the ASF.
>
> On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <pa...@gmail.com>wrote:
>
>> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jh...@apache.org> wrote:
>> > I would like to merge a branch from a non-committer[1]. The log shows
>> > a non-apache author, but an apache committer.
>> >
>> > What is the policy regarding this? I was thinking the following:
>> >
>> > 1. Merge freely and promiscuously from anybody in my GitHub (or
>> > whatever) repo (community engagement)
>>
>> Not quite. More below.
>>
>> > 2. As the branch nears time for "promotion," ask the non-committer to
>> > git format-patch and attach to JIRA, signing (checking) the license
>> > transfer.
>>
>> Unnecessary.
>>
>> > 3. With that settled, either git rebase or `git am` (I'm unclear about
>> > this). The point is, get an @apache.org committer id on each commit.
>>
>> Unnecessary.
>>
>> > 4. Push where appropriate into the ASF repo
>> >
>>
>> Included in discussion of 1 below.
>>
>> > Questions:
>> >
>> > Must the non-committer attach the exact same commit id? Or is it
>> > sufficient that it merely be the same diff (delta)? (I changed the ID
>> > when I rebased his commit and added my email to the committer header.)
>> >
>>
>> No. Commit SHA's are in no way important from a license perspective.
>>
>> > Before the JIRA license agreement, may we push non-committers' code to
>> > the repo at all?
>> >
>>
>> Kinda, see below.
>>
>> > Before the JIRA license agreement, may we push non-committers' code to
>> > the more official branches: master, 1.2.x, etc.?
>> >
>> > May we push whatever we want so long as the license agreement is
>> > signed (checked) before voting on a release artifact?
>>
>> For the last two questions, definitely not. Never push code to ASF
>> hardware that you're not 100% certain is OK to be in the repository.
>> That doesn't necessarily mean that it has to have the ASF license
>> attached, but if you don't know that it can be in the repo, don't push
>> it.
>>
>> First things first, as a committer you have to remember the ICLA that
>> you signed. Its your responsibility to make sure that all code you
>> push to the repository is compliant with ASF policies and the legal
>> aspects those entails.
>>
>> Before Git, the general policy we used in CouchDB was to request that
>> non-trivial patches be submitted to JIRA and have people click the
>> checkbox. While this captures the general intent of things, it has
>> been declared an official position of the board that this is
>> unnecessary for accepting contributions. It has also been decided that
>> the committer and author fields do not have to be tied to specific
>> Apache accounts.
>>
>> The policy as it stands now is that we must be able to demonstrate
>> that there was a clear intent for the code in question to be
>> contributed. While there hasn't been an official position on how to
>> demonstrate intent I think there are a couple things that are fairly
>> obvious:
>>
>> Traditional:
>>
>> 1. Same as always: Anything submitted to JIRA. The check box has been
>> declared not a necessity though I think the input field is required,
>> and if someone said "not-intended for inclusion" we should just
>> clarify if that was an accident or not.
>>
>> 2. Patches submitted to a mailing list.
>>
>> New with Git:
>>
>> 3. If someone posts a link to a publicly available Git branch with
>> language indicating their intent for it to be included, then we should
>> feel free to add the repo as a remote and yank it in. While not
>> absolutely necessary, it might be a good idea to rewrite the commit
>> message to reference either the email or the original contributed
>> commit sha (in case of a rebase) so that we can link the two.
>>
>> 4. Jukka Zitting has recently been doing work on connecting GitHub
>> Pull Requests to the dev@ mailing lists. Assuming this is the case I
>> think we should feel free to take any code submitted in this manner.
>> Thus our old "Submit that to JIRA" would be a "Send us a Pull
>> Request".
>>
>> In contrast, we shouldn't feel free to just find code in a random
>> GitHub fork and push that onto ASF hardware. If there's something we
>> see that we want then we should ask for clarification (plus that's
>> only polite).
>>
>> Bottom line, as a committer you're responsible for the code that you
>> push to the repository. If you're not sure on a specific patch or
>> situation, bring it up to dev@ or similar venue and we can run it up
>> the flag pole until we find an answer.
>>