Thanks Jason! On Sun, Mar 4, 2012 at 9:35 AM, Jason Smith <[email protected]> wrote:
> Converted to a wiki page: http://wiki.apache.org/couchdb/CommitPolicy > > On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <[email protected]> > 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 <[email protected]> > 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 < > [email protected]>wrote: > >> > >>> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <[email protected]> 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 >
