Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "CommitPolicy" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/CommitPolicy?action=diff&rev1=2&rev2=3 Comment: See https://couchdb.apache.org/bylaws.html - <<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+0qudjp9sqjsyb0i...@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. - - - > Does the author or committer of a commit have to be an ASF person? - - No. -
