http://lists.drupal.org/pipermail/development/2008-May/029761.html clearly demonstrates that documenting all of contributions on api.drupal.org would be good.
Add concept of projects every project has its own code and set of branches. This should be clear in both the database and UI.
Programmatically manage branch checkouts managing a lot of CVS checkouts would be tedious.
I researched speaking the CVS protocol to directly query the server. This would be tedious to write and might be hard to debug. Documentation on how to get the relevant documentation is at http://ximbiot.com/cvs/cvshome/cyclic/cvs/dev-res.html. I think it is best to keep checkouts in the filesystem.
Three types of branch management should exist:
- Filesystem, same as we do now, parse what is at the specified path.
- CVS, programmatically make/update a CVS checkout to the files directory using CVS root, CVS module, path, tag, etc. See http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project/rel... for an example of Drupal code doing this.
- SVN, lots of people use it for internal projects, API module should support it.
Programmatically create branch checkouts use update status XML, for example http://updates.drupal.org/release-history/api/5.x, to find and create project branches.
What can be done now:
- Update to Drupal 6. All menu changes should happen after this.
- Mock-up UI changes for project navigation and other additional UI elements.
- Clean up admin screen. It will have to scale a lot more.
- Try running API module with modules you use. Pay attention to what works and what is annoying, report your findings here.
- Establish standards for hook and @mainpage documentation in contributions.