bzr and Drupal. We now have a bzr mirror of the core. It's easier for a group of people to work on a bigger change in their own branch and submit a final diff. (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr branch, too and then instead of patches we may submit a link to a bzr branch instead of a patch file but this is not so important. We will provide and advertise a readonly bzr mirror for all contrib directories. If the module maintainer decides that he he does not want to deal with CVS but uses bzr instead, he will have a checkbox in project module to indicate that (or if we do not want project change, just text that). If it's a bzr maintained module then you can contribute two ways: a) send in patches (like now) b) from the bzr mirror, create your branch and submit a link to the maintainer. When the maintainer wants to commit changes back to the repo, he merges changes and pushes that to a private branch. When this push happens, a simple script is run, which commits these changes back to cvs, and from there we mirror to bzr and the cycle is complete. The problem is -- how we avoid conflicts? Simply, if a module is bzr maintained, then we make it clear that you should not commit into the CVS repository dir by the means of CVS. Either submit a patch (as you do now) or use bzr but do not commit into that dir. Ideally, cvs.drupal.org rejects this kind of commit by the means of a pre-commit script. Lacking that, the bzr to cvs script will take care of it. Then this script needs to track of the revision of the cvs revision of the files in the readonly bzr mirror (first ancestor): # check out the first ancestor cvs co foo -r$known_revision # make sure the cvs is in that state cvs commit # bring in the new/changed files bzr pull $maintainers_private_branch # make sure CVS knows about new files cvs add * # put the log into an obscure named file bzr log $maintainers_private_branch -r -1 >__bzr__log # reuse that for cvs log message cvs com -F __bzr__log Yes, that's the actual script. Advanced versions will be able to branch for Drupal versions. Even that should not be too hard, because the bzr mirrors (including the maintainers_private_branch) will have directories modules/eventrepeat/4.6 -- one dir for every Drupal major version. Updating the readonly bzr mirror is easy: cvs up -dP bzr commit Probably the scripts will be written in PHP and linked through the database -- after all, you need store somehwere the known_revision and maintainers_private_branch. The __bzr__log also should be saved and reused when commit in the readonly space. Or to maintain simplicity maybe we could get away even with some bash scripts which store info in text files. Caveat: I am no expert of that. (note. file additions and removals needs to handled. Maybe tailor will be used here.) If the module is a CVS maintained one, then those that are on the bright side can _still_ use the readonly bzr mirror only they are not submitting bzr branch links but patches. Let's see some benefits: The necessary scripts are simple. If someone wants to run cvs update -- (s)he can do that. If a module/theme/translator maintainer is sick of cvs -- there is bzr. Also, a web upload interface is coming for bzr. If a module/theme/translator maintainer wants to use cvs -- (s)he does not need to face bzr yet his/her contributors can use that and submit patches. What's lost? If a module is bzr maintained then you can't just walk in and do an update of the module. The maintainers' responsibility is bigger. Solution? Multiple maintainers with a $maintainers_private_branch for each maintainer. You still can't just walk in, but there always will be someone who can commit your change. Note that this is pretty rare, as most module maintainers do not like if you commit into their directory in the current situation. One more thing: there should be another privilege level, they can commit against any module. Note that we do not need to change _anything_ in the modules currently used Drupal.org! Still CVS is the common denominator This is a plan which needs time. Also, bzr itself needs some time. I do not plan on posting the whole Drupal community through drupal.org until bzr 2.0 is out next spring.