couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Advice on policy merging non-committer branches
Date Wed, 29 Feb 2012 08:51:38 GMT
Thanks Paul. My question was prompted by COUCHDB-1416. The policy is
much more common sensible than I feared it would be. It looks like
Ryan's (patch|commit|branch) is good to go.

On Wed, Feb 29, 2012 at 11:34 AM, Paul Davis
<> wrote:
> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <> 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 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

View raw message