couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "CommitPolicy" by JasonSmith
Date Sun, 04 Mar 2012 09:33:34 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change 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)>>

= Committer Git Policy =

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

Git (and GitHub) reduce the (technical) friction of receiving patches to CouchDB, 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/mod_mbox/couchdb-dev/201202.mbox/%3CCAJ_m3YBdyeJZMuEuGZiBC=fpkc7ZB=v+0qUdJp9sQJsYB0iTAw@mail.gmail.com%3E|email
about the topic]].

== Background ==

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

 1. 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.
 2. 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.

== FAQ ==

> 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% 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.

Mime
View raw message