Last updated April 15, 2012.

The following documentation is meant for the people that were in the middle of their CVS Application process when the change to Drupal.org using Git happened (late Feb 2011).

What is Git?

Git is another version control system (like CVS) but is a distributed model, as opposed to a centralized model. This has many benefits, but that is not the scope of this documentation. Please read up at the main git documentation, introduction to Git, and the Git FAQ.

What does this mean for you?

This change is monumental for the Drupal community and for you. It means that CVS Applications are a bit obsolete. But with some simple steps (that will allow you to learn Git) you can get back on track and contributing code to Drupal.org. Here are the major changes that are happening around access to committing code on Drupal.org:

  • The biggest change is that everyone now has the ability to have full-featured sandboxes (or experimental projects), given you have agreed to new terms. This means you have a place to put your code and version it out right away with an issue queue and everything.
  • The main issue with experimental projects is that you cannot create releases, this is where full projects come in. Once approved, you will have the permission to create a full project. This is what is equivalent to the CVS Application.

Benefits

Please note that this new system had you (people applying to CVS) in mind. The community has been aware for some time that the CVS application process had become unwieldy and a very negative experience for lots of people doing it. This new system attempts to start addressing this by hopefully producing the following benefits.

  • Since you can now version your code on Drupal.org, the necessity to have a full project may lessen, reducing the number of full project applications and their time for approval.
  • Experimental projects now have issue queues which will allow for feedback from the community in a more structured and open way. This should allow users to create a more stable module before going to the full project application, again possibly reducing time for approval.
  • Having a standard repository for all application projects will make it easier for reviewers to review applications, thus reducing approval time.
  • Experimental projects can have co-maintainers. This is like pair-programming and should raise the quality of the project more quickly and thus reduce approval time.
  • Though you might not see this, moving to Git and experimental projects, creating an automated system to check coding standards and basic metrics like that will be easier, lessening the time for approval.

Going forward

The following are steps to go forward. If you are applying as a co-maintainer, please ignore the code parts.

  1. Learn about Drupal.org and Git.
  2. Read the usage policy, agree to new terms, set up your profile, set up your local Git, and upload your SSH key.
  3. Create an experimental project of the project you included in your CVS application.
  4. IMPORTANT: If you feel that this is a good place for you to continue to develop the project and get more people contributing, please just continue with the experimental project and look to apply for the full project permission later.
  5. Read the new application instructions, and if you feel that your project is still in a good, stable place, convert your CVS application to a Full Project application with the following steps:
    1. Add comment to your current application.
    2. Change the Project from Drupal.org CVS applications to Drupal.org Project applications.
    3. Change status to Need review.
    4. Add a link to your new experimental project that should be reviewed and any description of updates that may have happened, if your application is for a new module.

Questions?

Please see this issue as to how this particular process was created.