*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 <[email protected]> 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 <[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. >> >> >>
