Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received-SPF: pass (google.com: domain of jhs@iriscouch.com designates
 10.52.179.10 as permitted sender) client-ip=10.52.179.10;
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YDQGcW3ikadLLhdqMkDL8tMrYH1psZyEMke5fb4QHbhxg@mail.gmail.com>
References: 
 <CAN-3CB+1KTBREXji8mjy-FK97eBr4jivrE0-C7R=EwFF1QvdrQ@mail.gmail.com>
 <CAJ_m3YBdyeJZMuEuGZiBC=fpkc7ZB=v+0qUdJp9sQJsYB0iTAw@mail.gmail.com>
 <CA+Y+446yAgkzJUWMR6CGBpEG28DzAM4YMq_Crd-QQeHKk_xjPg@mail.gmail.com>
 <CAJ_m3YDQGcW3ikadLLhdqMkDL8tMrYH1psZyEMke5fb4QHbhxg@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Sun, 4 Mar 2012 09:35:19 +0000
Message-ID: 
 <CAN-3CB+aWXXYTLeXQ6wG=rypkkWypYA9mUnnzSQQ-pjsQ=aARA@mail.gmail.com>
Subject: Re: Advice on policy merging non-committer branches
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

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

On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <paul.joseph.davis@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 <nslater@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 <jhs@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