Migration Roadmap

While a roadmap might not be well-suited for a caterpillar striving for butterflyhood, it's absolutely necessary for this migration. There's a lot of different work that needs to be done by a lot of different people, simultaneously, and there's a lot of interdependencies between the pieces. I've now finally come up with a roadmap that lays out all those disparate areas (HUGE thanks to webchick for her help with this). We initially tried to put it in text so that it could be posted here directly, but ended up moving to a spreadsheet (in a google doc) because it was a better medium for capturing the simultaneous nature of the work. This roadmap is my daily working document, and I'll be updating as the process moves along.

Important note: I'm publishing this roadmap because it's essential to making the process transparent - not because I think it's the most useful thing for folks to look at. I'm committed to doing this entire migration via issues in the Drupal.org queues, so the only reason to look at this is if you want the 10,000ft view.

There's a lot of shorthand on the roadmap, so lemme break down the meaning of each grouping/track:

1. Versioncontrol Architecture - For this initial phase, the new infrastructure is being built on top of Versioncontrol API. VC API is responsible for doing lower-level server-side interaction with repositories, creating ACL groups, ensuring git's hooks are doing their thing, and generating commit listings. We're focused on getting the 2.x branch finished.
2. Workflow User Stories - This is one of the most important things to get accomplished right now. We need to lay out, step-by-step, all the ways in which people currently interact with Drupal's CVS, and agree on appropriate step-by-step counterparts for git. A lot of writing, and a lot of 'deciding' for this one; when completed, though, we'll have clear answers to a lot of questions related to the UI, etc.
3. Project UI - Anything that's going to affect the d.o UI falls into this grouping. That includes, for example:
   1. The project creation page
   2. Managing a project's maintainers (though this will probably look exactly the same as it does now)
   3. Setting branch release status (e.g., http://drupal.org/node//edit/releases)
      Work in this area tends to fall into some combination of Project module and Versioncontrol Project, which is the bridge between VC API and Project. This is all heavily dependent on the outcome of user stories discussion, and is therefore marked to start after it.
4. Open Source Training Curriculum - I want to put together a 'curriculum' for teaching git to drupallers. It would have two parts: first, a set of learning objectives, which together comprise all the basics people need to know to interact with drupal's git infrastructure; second, reusable presentation materials people can reuse to create their own git trainings (for drupalcons, drupalcamps, in the workplace, etc.) that help meet the objectives. This is all significantly dependent on the user stories, so very little can be explicitly planned until those are done.
5. Migration Path - While the basics of the migration path have been determined, there's still more tests that need to be run - for example, 1-2% of projects currently fail to import flawlessly and we don't know why. This grouping also includes setting up automated runs of the migration path on a daily basis.
6. Packaging & Update system - All of Drupal.org's packaging scripts are currently heavily tied to CVS. These, as well as the server-side systems that generate the update xml, need to be updated to git.
7. Server Setup/Configuration - The migration entails a number of changes to the way d.o's serverside infra operates; certain UNIX accounts will need to be created, ssh and git need to be set up, and we need to figure it all out and start testing it. This very much dovetails with setting up automated runs of the migration path.
8. Collect Contributor Information - Some of the migration will require us contacting current CVS account holders & project maintainers to get information. The biggie is deciding what to use for the 'Name' and 'Email' fields git uses, but we also need to figure out how to handle the small percentage of modules that don't import flawlessly.

If/when groupings get added or seriously modified on the spreadsheet, I'll update their descriptions here. And if someone has a better suggestion for a more participatory/more convenient/more entirely-on-d.o way of handling this, I'm very open to suggestions :) For it to be useful and non-laborious for me to use, though, I need it to a) show the tracks in parallel as the spreadsheet does, and b) still be really easy to update.

Hopefully, this roadmap conveys the overall thrust of my approach to making this migration happen: get as much of the interdependent work and decisionmaking done as early as possible, and kick off each parallel work track as soon as it has its prerequisites met.

So, without further delay - The Roadmap!