Dear wiki user, You have subscribed to a wiki page "Couchdb Wiki" for change notification.
The page "GitSuccessCriteria" has been deleted by JoanTouzet: https://wiki.apache.org/couchdb/GitSuccessCriteria?action=diff&rev1=14&rev2=15 Comment: Git has now happened! Hooray. - = Criteria for GIT @ ASF = - This list describes all points which MUST be met for GIT to become an accepted SCM for ASF projects. - . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [[http://www.ietf.org/rfc/rfc2119.txt|RFC 2119]]. - - == Technical == - 1. The preservation of the commit history MUST be guaranteed. It SHOULD be practically impossible to delete, tamper with, or alter any piece of commit history which made it into an official ASF release. - 1. Changes MUST be submitted by an authenticated committer, over a secure connection. It SHOULD not be possible to fake the committer id and thus taint the commit history. - 1. In cases where the committer is not the author, the committer is REQUIRED to ensure that the author has granted the code to the ASF under the terms of the [[http://www.apache.org/licenses/LICENSE-2.0|Apache License]] or that the contribution is sufficiently trivial to waive this requirement. - 1. The single canonical project repository (repositories) MUST be hosted on ASF servers under full control of the ASF infra team. - 1. There MUST be no other legal problem because of the usage of GIT as canonical repository. - 1. The canonical GIT repo hosted at the ASF MUST be the repo to cut official ASF releases from. - 1. ASF Infrastructure MUST provide backups of the repository and MUST be able to guarantee reasonable uptime of the services. - 1. A set of community policies or procedures SHALL be defined, and the community SHALL review them to ensure that any impact due to GIT implementation is either mitigated or accepted. - - == Community Policies and Procedures == - 1. How committers are RECOMMENDED To handle branches, including development, feature, official releases, and maintenance branches. - 1. How to handle security@ issues, and what material SHOULD NOT be committed to the repository. - 1. A documented and accepted Release procedure MUST be defined and followed. - 1. It is RECOMMENDED that a clear community contribution process is made available. - - == Relevant discussions and documents == - . The following are links to the official ASF CouchDB mailing list archives. You can click on arrows in the right-hand side to view replies. - - [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201109.mbox/<400b8fd70f37440e98f7d00632936...@gmail.com>|Disabling svn access 2011/09/23]] - - [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201109.mbox/<CAJ_m3YB13xYApF3mdW3CFQxHq9ym72Nv9T_MfYOEp=hkctn...@mail.gmail.com>|Approval from ASF to start the Git Experiment 2011/09/29]] and [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/201108.mbox/<4e36d474.1090...@couchone.com>|continued]]. - - . The following are documents relating to the above criteria. - - The [[Release_procedure|Release Procedure]] contains an up to date process for releasing CouchDB from sources maintained in ASF-controlled GIT. - - There is a [[http://wiki.phonegap.com/w/page/28618504/Git%3A%20Contributor%20Workflow|Git Contributor Workflow on the PhoneGap Wiki]], which is a great outline on how to use git when you want to contribute patches. - - == Success Measurement == - TODO: Every experiment has variables which are measured to decide about the success of the project. - - How has the community changed with git? - - * Are there new committers elected while git, how was it in the months before? - * How many patches were contributed while the experiment ran, and before? - * Has the couchdb user community given feedback on the change? - * Has the number of commits reduced while using git? - * Has the quality of the commits increased while using git? - * Were there cases of misunderstandings with distributed repositories? -
