(TL;DR? Here's summary #1: http://groups.drupal.org/node/114264#comment-367134)
For those who have not been following along with the CVS -> Git migration progress, this post contains important information for you to be aware of.
Things that we know:
- Once Git launches, anyone with a Drupal.org account will be able to commit code to Drupal.org.
- In order to get Git commit access, you will need to read and agree to the Developer Terms of Service in your user profile which includes items like "I will only upload GPL compatible code" (basically, the same agreement people have to agree to on the CVS application form right now).
- There will from now on be two types of projects you can create: "sandbox" projects (which all users can create) and "regular" projects (which approved users can create). They share basic common features--a project page, committer access, issue queues, etc.--but with a few key differences:
- Sandbox projects get a numeric shortname repository based on their project node IDs (like 12345.git) to indicate that they are "experimental" so that they don't take up a "proper" repository's namespace.
- You cannot create releases of sandbox projects. The only way for users to get the code of a sandbox project is with
git clone. - Sandbox projects are not visible in search results, listing pages, main issue queue listings, etc. Basically, they can only be accessed from the author's user profile.
- There will be some visual indicator on a sandbox project node page to indicate that it's experimental (Exact nature TBD: See http://drupal.org/node/984734)
- The security team has no responsibility over code in sandbox projects.
- A sandbox project can be made into a regular project at any time via a checkbox by those who have permissions.
- There will be an approval process of some kind, similar to the existing CVS account approval process, but far less daunting and time consuming, because:
- It will focus only on "big impact" items: overall understanding of Drupal's APIs, security review, license compliance, blatant duplication of other projects.
- Reviewers can use standard tools like commit logs, diff, and the issue queue to understand the code and its evolution and get a "sense" of the maintainer, thus removing a lot of pain and guesswork from the approval process.
- All non-critical follow-ups (coding standards compliance, naming conventions, etc.) can be handled in the standard issue queue way, and addressed by the author either prior to or after their sandbox makes the transition to a regular project.
The last piece is deciding how the permissions to create "real" projects are allocated.
Option #1: The "Keep things as they are" approach:
- All pre-existing CVS account holders will receive permissions to promote their own sandbox projects to real projects; their access wouldn't change.
- If you are not a pre-existing CVS account holder (which means all new module/theme contributors post-Git migration), you will need to go through a one-time approval process in order to get these permissions.
- Quality control standards on new projects aren't changed in any way.
Option #2: The "Approval for every project" approach:
- All projects must go through an approval process, regardless of who the author is.
- Approvals theoretically will go faster because everyone's in the same boat, from merlinofchaos to someone with a 7-digit user ID. (though it's possible that special roles could be granted to prolific contributors)
- A higher standard of quality control will be placed around new contributed modules, because each one must pass a review of their peers.
Because the migration team's goal is to minimize the impact of the CVS to Git migration, both for community health and time/budget reasons, and because option #2 could always be implemented at a later date if wide consensus is reached that it's a good idea, the Git team strongly advocates implementing option #1. In other words, we keep the status quo for existing and new contributors, and do not introduce additional approval mechanisms into the contribution process.
We are opening a period of community feedback until no later than January 5, 2011. Please speak now or forever hold your peace. Or at least hold it until after the Git migration goes live (currently scheduled for mid-February 2011). :)