Today Ohloh finished importing the Launchpad source code and produced the first source code analysis report. There seems to be something fishy about the reported line counts (e.g. -3,291 lines of SQL), but the commit counts and contributor list look about right. If you’re interested in what sort of effort goes into producing an application like Launchpad, then it is worth a look.
One of the nice features of Bazaar is the ability to send a bundle of changes to someone via email. If you use a supported mail client, it will even open the composer with the changes attached. If your client isn’t supported, then it’ll let you compose a message in your editor and then send it to an SMTP server.
GMail is not a supported mail client, but there are a few work arounds listed on the wiki. Those really come down to using an alternative mail client (either the editor or Mutt) and sending the mails through the GMail SMTP server. Neither solution really appealed to me. There doesn’t seem to be a programatic way of opening up GMail’s compose window and adding an attachment (not too surprising for a web app).
What is possible though is connecting via IMAP and adding messages to the drafts folder (assuming IMAP support is enabled). So I wrote a small plugin to do just that. It can be installed with the following command:
bzr branch lp:~jamesh/+junk/bzr-imapclient ~/.bazaar/plugins/imapclient
And then configure the IMAP server, username and mailbox according to the instructions in the README file. You can then use “bzr send” as normal and then complete and send the draft at your leisure.
One nice thing about the plugin implementation is that it didn’t need any GMail specific features: it should be useful for anyone who has their drafts folder stored on an IMAP server and uses an unsupported mail client.
The main area where this could be improved would be to open up the compose screen in the web browser. However, this would require knowing the internal message ID for the new message, which I can’t see how to access via IMAP.
One thing that has been mentioned in the GNOME DVCS debate was that it is as easy to do “git diff” as it is to do “svn diff” so the learning curve issue is moot. I’d have to disagree here.
Traditional Centralised Version Control
With traditional version control systems (e.g. CVS and Subversion) as used by Free Software projects like GNOME, there are effectively two classes of users that I will refer to as “committers” and “patch contributors”:
Patch contributors are limited to read only access to the version control system. They can check out a working copy to make changes, and then produce a patch with the “diff” command to submit to a bug tracker or send to a mailing list. This is where new contributors start, so it is important that it be easy to get started in this mode.
Once a contributor is trusted enough, they may be given write access to the repository moving them to the committers group. They now have access to more functionality from the VCS, including the ability to checkpoint changes into focused commits, possibly on branches. The contributor may still be required to go through patch review before committing, or may be given free reign to commit changes as they see fit.
Some problems with this arrangement include:
Distributed Workflow
A DVCS allows anyone to commit to their own branches and provides the full feature set to all users. This splits the “committers” class into two classes:
The social aspect of the “committers” group now becomes the group of people who can commit to the main line of the project – the core developers. Outside this group, we have people who make use of the same features of the VCS as the core developers but do not have write access to the main line: their changes must be reviewed and merged by a core developer.
I’ve left the “patch contributor” class in the above diagram because not all contributors will bother learning the details of the VCS. For projects I’ve worked on that used a DVCS, I’ve still seen people send simple patches (either from the “xxx diff” command, or as diffs against a tarball release) and I don’t think that is likely to change.
Measuring Success
Making the lives of core developers better is often brought up as a reason to switch to a DVCS (e.g. through features like offline commits, local cache of history, etc). I’d argue that making life easier for non core contributors is at least as important. One way we can measure this is by looking at whether such contributors are actually using VCS features beyond what they could with a traditional centralised setup.
By looking at the relative numbers of contributors who submit regular patches and those that either publish branches or submit changesets we can get an idea of how much of the VCS they have used.
It’d be interesting to see the results of a study based on contributions to various projects that have already adopted DVCS. Although I don’t have any reliable numbers, I can guess at two things that might affect the results:
I am sure that there are other things that would affect the results, but these are the ones that I think would have the most noticeable effects.
Yesterday, a BoF was scheduled for discussion of distributed version control systems with GNOME. The BoF session did not end up really discussing the issues of what GNOME needs out of a revision control system, and some of the examples Federico used were a bit snarky.
We had a more productive meeting in the session afterwards where we went over some of the concrete goals for the system. The list from the blackboard was:
The sys admin tasks were broken down to:
It was clear from the discussion that neither Git or Bazaar satisfied all of the criteria.
The Playground
John Carr did a great job setting up Bazaar mirrors of all the GNOME modules. This provided an easy way for people to see play around with Bazaar. However, it only gave you half the experience since it didn’t provide a way to publish code and collaborate.
To aid in this, we have set up the bzr-playground.gnome.org machine, which any GNOME developer should be able to use to publish branches based on John’s imports. Instructions on getting set up can be found on the wiki. I hope that we will get a lot of people trying out this infrastructure.
We gave a presentation today on some of the things Bazaar provides that could be useful when hacking on GNOME. Demoing bzr-playground was a bit problematic due to the internet connection problems at the venue, but I think we still showed some useful tools for local collaboration, searching and code review.
Meanwhile, Robert Collins has been working on some of the GNOME sysadmin features that Bazaar was lacking. Among other things, he got Damned Lies working with both Subversion and Bazaar, with a test installation on the playground machine.
It has been a while coming, but MySQL has announced their move to Bazaar for version control. This has been a long time coming, and it is great to finally see it announced publicly.
The published Bazaar branches include 8 years of history going back to MySQL 3.23.22, imported from the BitKeeper repositories. So you can see a lot more than just the history since the switch: you can use all the normal Bazaar tools to see where the code came from and how it evolved. Giuseppe Maxia has posted some instructions on how to check out the code for those who are interested.
I haven’t checked extensively, but I wouldn’t be surprised if this is the largest public code base managed with Bazaar. I’ve known from personal experience working on Launchpad that it is capable of handling large trees, but it is good to have a high profile project to point at as an example now.