Dear wiki user,

You have subscribed to a wiki page "Couchdb Wiki" for change notification.

The page "GitSuccessCriteria" has been deleted by JoanTouzet:

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 [[|RFC 
- == 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 [[|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 
- == 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.
 svn access 2011/09/23]]
 from ASF to start the Git Experiment 2011/09/29]] and 
-  . 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 
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 
-  * 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?

Reply via email to