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 Wed, 29 Feb 2012 04:34:36 GMT
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