Existing contributor test plan

Things project maintainers should verify before the Git migration.  This involves some test commits and branches and release and stuff, which we can’t encourage you to do on the live drupal.org once this is deployed for real.

Setup

1. Do you have Git installed locally so you can manipulate your project’s code?  See http://drupal.org/node/1010894 for help with this.
2. Have you agreed to the terms of service? Even though contributors will have the privilege to create full projects imported on their behalf, you will NOT be able to exercise those privileges unless you agree to the new (although not incredibly different) terms of service. See http://drupal.org/node/1047190 for details.
3. Have you identified yourself properly to Git so your commits are associated with your account?  See http://drupal.org/node/1022156 for more.

Verify project data

We need ALL maintainers to verify the integrity of their project’s data ASAP, to help spot-check that the data was migrated correctly. These are the most important things to check:

1. Go to your project page on http://git-dev.drupal.org/ and check that the Maintainers block shows the information that it should (note that the number of commits will differ between drupal.org and git-dev.drupal.org, but the names and dates should be the same).
2. Clone your project and ensure all the expected branches and tags show up. The “Git instructions” tab has more information on Git commands, but roughly this looks like the following:
   
   // TODO: Please verify this; I’m typing blind and also do not know what I’m doing :)
# Obtain a copy of project from Git.
git clone http://git-testing.drupal.org/project/[project-name].git

# Inspect all available branches.
git branch -r
# Shows output similar to:
# origin/5.x-1.x
# origin/6.x-1.x
# origin/HEAD -> origin/master
# origin/master
  
# Inspect all available tags.
git tag
# Shows output similar to:
# 5.x-1.0
# 5.x-1.1
# 6.x-1.0
# 6.x-1.1
# 7.x-1.0
# 7.x-1.0-alpha1
3. Actually install one or more variations of your project using git checkout [tag-or-branch] and ensure you can enable it and it functions properly. Try git checkout master to get back to "HEAD"

If you are one of our rockstar contributors who has many dozens of modules who can't possibly do this on all of your projects, please focus your attention on those projects that are particularly complex and idiosyncratic, or ones that are extremely popular with lots of users.

Work with an existing repository

1. Try locally cloning the Git repository for one of your projects.  See the “Git instructions” tab on that project for more details.
2. Try to make some commits to your local repository, then push them to the “upstream” repository for your project on drupal.org.  Again, see “Git instructions” for details.
3. If your project is set up to be tested by PIFR, verify that the test occurs after you do the commits and comes out correctly. You can see a "branch" test at http://qa.scratch.drupal.org/pifr/log/recent
4. If your project is set up to be tested, post patches to the issue queue and verify that testing is done correctly. See http://groups.drupal.org/node/126409
5. Create a new branch for your project for new development on a new major version, e.g. if you’ve already got a 7.x-1.x branch, create a 7.x-2.x branch.  Push this branch to the upstream repository.  Try to make a new development snapshot release node pointing to this branch.
6. Create a new branch for a one-off feature, not a whole new release series.  E.g. 7.x-2.x-something-cool.  Push this repository upstream.  Try to make a release node and ensure you do NOT see this branch as an option.  Only branches (and tags) that follow specific conventions are allowed for creating release nodes.
7. Make some changes (even if bogus) on your new feature branch and commit them.  Push your commits upstream.  Verify the commits show up on your project page (in the “view commits” page off of your project, e.g. http://git-dev.drupal.org/node/3060/commits even though it’s for a non-releasable branch.
8. Try to merge your 7.x-2.x-something-cool branch back into the 7.x-2.x branch and push the merge upstream.  Make sure you understand what’s going on.  Verify the merge is visible as a commit on your project page.
9. Tag the 7.x-2.x branch with a 7.x-2.x-something-cool-is-done tag.  Try to create a release.  Make sure “7.x-2.x-something-cool-is-done” is not an option.  Again, only certain well-formed tags are allowed for release nodes.
10. Tag the 7.x-2.x branch with “7.x-2.0-unstable1” (a valid release tag) and try to create a release node.  Make sure it works.  (Optionally, use the new Git-friendly release note generator script (git-release-notes, tgz drush extension at https://github.com/JoshTheGeek/git-release-notes/tarball/6.x-2.2) and see if it figured out the right changes for this release. Wait ~10 minutes (e.g. continue down this list) and then download the 7.x-2.0-unstable1 .tar.gz and .zip files.  Unpack them.  Make sure they include the (potentially bogus) changes to your source code that you added in step #7 above. Note: Releases do not appear in Administer releases until they have been packaged, which happens every 5 minutes for stable releases and twice daily for development releases.

Work with someone else's repository

1. Clone the Git repository from a project you do NOT co-maintain.  Commit some changes to your local clone.  That should work.  Try to push those changes back upstream.  That should fail.  If not, please tell us. ;)
2. (If you’re a co-maintainer but not an owner of a project) Try to clone, commit, and push changes to a project’s repo that you co-maintain.  Everything should work.

Work with a sandbox

1. Try creating a new sandbox project.
   1. Create the node (and give it a very unique title so you can test searching for it later without having to read through too many search results, see below)
   2. See that it shows up as a sandbox on the “Your Projects” tab under your account
   3. Make sure you can’t create any releases for it
   4. Try to push code into its repository
   5. Try to create issues for it
   6. Make sure those issues show up at the “Your Projects” page
   7. After at least 15 minutes have passed since step a, search for it at the modules browsing page (http://git-dev.drupal.org/project/modules)
      • make sure it’s not visible there by default
      • make sure you can see it once you select either “Only sandbox projects” or “All projects” under the “Status:” exposed filter
2. Try to promote your new sandbox project from step #1 into a full project.  Note that you’re not necessarily going to do this regularly, but it’s worth making sure it works if you need to do it. ;)
   1. visit the project page for the sandbox project
   2. click the "Promote to full project" link
   3. confirm that you want to promote the project
   4. give the project a short name. When the Git migration goes live, you'll only get one shot at this, so get into the habit of double-checking that it's what you want.
   5. enable releases, or not. You can change this later.

Make a new project

1. Try to create a new full project directly (without creating it as a sandbox and then promoting it).
2. Check out the “Repository viewer” link from the “Development” block on your project page, e.g. http://git-testing.drupalcode.org/project/views.git -- make sure you can see your commits, your branches and tags, find your way around, etc.
3. Find a patch in your issue queue and try to apply it to your local checkout of your project.  Make sure you can figure out how to apply the patch.  Commit it.  Push the change.  Make sure all is cool.