incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Advice on policy merging non-committer branches
Date Sun, 04 Mar 2012 03:08:42 GMT
*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 <nslater@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 <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.
>> >>
>>

Mime
View raw message