Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Sun, 04 Mar 2012 09:33:34 -0000
Message-ID: <20120304093334.81621.37739@eos.apache.org>
Subject: 
 =?utf-8?q?=5BCouchdb_Wiki=5D_Update_of_=22CommitPolicy=22_by_JasonSmith?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for c=
hange notification.

The "CommitPolicy" page has been changed by JasonSmith:
http://wiki.apache.org/couchdb/CommitPolicy

Comment:
Import and reformat Paul's email

New page:
<<Include(EditTheWiki)>>

=3D Committer Git Policy =3D

This page explains policies about receiving integrating your work (as a Cou=
chDB committer) with non-committers' work, with an emphasis on using Git.

Git (and GitHub) reduce the (technical) friction of receiving patches to Co=
uchDB, so this page should clarify what to do and not to do to stay within =
Apache's policy.

This page is derived from Paul Davis's [[http://mail-archives.apache.org/mo=
d_mbox/couchdb-dev/201202.mbox/%3CCAJ_m3YBdyeJZMuEuGZiBC=3Dfpkc7ZB=3Dv+0qUd=
Jp9sQJsYB0iTAw@mail.gmail.com%3E|email about the topic]].

=3D=3D Background =3D=3D

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:

=3D=3D=3D Traditional =3D=3D=3D

 1. Same as always: Anything submitted to JIRA. The check box has been decl=
ared not a necessity though I think the input field is required, and if som=
eone said "not-intended for inclusion" we should just clarify if that was a=
n accident or not.
 2. Patches submitted to a mailing list.

=3D=3D=3D New with Git =3D=3D=3D

 1. If someone posts a link to a publicly available Git branch with languag=
e indicating their intent for it to be included, then we should feel free t=
o 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 t=
he email or the original contributed commit sha (in case of a rebase) so th=
at we can link the two.
 2. Jukka Zitting has recently been doing work on connecting GitHub Pull Re=
quests to the dev@ mailing lists. Assuming this is the case I think we shou=
ld feel free to take any code submitted in this manner. Thus our old "Submi=
t 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).

=3D=3D=3D Bottom Line =3D=3D=3D

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.

=3D=3D FAQ =3D=3D

> 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 the "Pushing to ASF" section above.

> 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?

Definitely not. Never push code to ASF hardware that you're not 100% certai=
n 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 t=
he repo, don't push it.