bzr now running on Natty + python 2.7

We just did one final tweak to bzr to be compatible with python2.7 for natty.

Vincent tells us that babune is finally blue running the test suite, and Jelmer says that the daily builds of python now finish for natty. Yay!

farewell, Ian

I am grieved to say that my friend and colleague Ian Clatworthy died last night, after a long and horrible struggle with cancer. He and his wife Geri celebrated their 19th wedding anniversary yesterday before he passed away peacefully in his sleep, at home, with his family.

I’ve known Ian for eleven years and he has worked at Canonical since 2007. He made large contributions to Bazaar, including launching and driving the bzr-explorer project. Even though he had many technical and business achievements, the most remarkable and inspiring thing was what a thoroughly nice man he was. He was determined to change the world for the better, both in software and in how people relate to each other, and he accomplished both. He will be missed, and remembered.

- Martin

[edit: add picture]

bugzilla-bzr integration

Max Kanat-Alexander’s new bugzilla-vcs extension (alpha) supports bzr, svn, hg, git, and cvs. Currently it supports linking bugs and commits, and displaying information about about commits in Bugzilla on the show_bug page.

Bazaar Team Foundation Server plugin

John Barlow’s new Bazaar TFS plugin adds support for Microsoft Team Foundation Server repositories, allowing one to use Bazaar to branch, merge, and commit code to remote TFS repositories.

bzr 2.2 releasing in July

We’re going to release bzr 2.2b4 this week, which will be the final beta for the bzr 2.2 series and the start of the 2.2 release branch.  From this point on the 2.2 will be an API freeze, so that any plugins that are updated to work with 2.2b4 will also work with 2.2.0 and future bugfix updates.  We plan to do 2.2.0 at the end of July.

2.2 brings a bunch of performance, correctness and usability improvements.

nice fast grep

Parth announced bzr-grep 0.2.0.  Amongst other things there are performance enhancements such that Eli says:

Thanks, this looks great. I just tried it on Windows XP searching for a fixed string in the Emacs repository — took 28 seconds with a cold cache and only 7.5 with a warm cache, which is impressive.

By contrast, “grep -F -R” (with suitable –exclude patterns, to prevent it from searching binary files and inside .bzr) took about 12.5 seconds with a warm cache.

poll: how long should we support stable series?

Every six months, the Bazaar team makes a major release, like the recent 2.1.0. This starts a stable series of bugfix-only updates that lasts for at least six months: no format or network changes, minimum chance of regression, and no disruption to plugins or other API clients. The idea is that people can install a major release, perhaps standardize their team on it, and then get fixes but no disruptive upgrades.

We’ve been doing this for just over a year now, and it’s going very well: the point releases are getting into the update channel for Ubuntu, Fedora, and other distros.

Now we have two stable series currently supported, with 2.0.5 and 2.1.1 just recently released, and 2.2b1 coming out at the end of this week.

We’re wondering: how long should we maintain these series, and how often should we do releases from them? On the code side, maintaining multiple branches in Bazaar is pretty easy, but making installers for all platforms, uploading and announcing them does take some work for every release we do.

At the moment I’m leaning towards supporting each of them for at least a year, but perhaps pushing out the interval between bugfix updates on stable branches: perhaps every two months, unless a critical bug is fixed.

What do you think? Are you using, or thinking of using a stable-series release of Bazaar? Would upgrading to a new stable branch every year be realistic? Are you getting bugfixes at about the right rate?

Bazaar Explorer’s Killer Feature

Bazaar Explorer 1.0.0 hits the streets yesterday. It’s now well entrenched in my Top 5 applications along with Firefox, Thunderbird and gvim – I truly love using it. Some user docs are coming but in the meantime, here’s a quick look at my favorite feature … project-specific tools.

The first time I opened a repository called “bzr”, Explorer guessed that I was working on the core Bazaar project and asked if I wanted to use the bzr “Hat”. I replied Yes. Now, every time I open a branch in that repository, my toolbox magically gets a Bazaar Development section as shown below.

The first 3 actions take me to the Open Questions, New Bugs and Active Code Reviews for bzr on Launchpad. That lets me reply to support questions, triage new issues and review merge proposals. Clicking on Servers pops up a menu of bzr-related web sites I visit from time to time, the PQM bot that merges proposed changes to our mainline (if and only if all tests pass) and our Hudson continuous integration server (that runs our regression test suite on lots of  different operating systems).

Likewise, Docs pops up a menu of documentation I commonly use …

BTW, you don’t need to be using a shared repository for Explorer to propose using a Hat for given location and its subdirectories. Opening a branch or checkout with the right name will work as well. If you don’t want to use a Hat for a location, that’s equally fine. Explorer will remember that fact and not ask you again.

This feature isn’t only for “bzr” development either. Explorer ships with around 20 hats for a variety of popular open source projects on Launchpad including MySQL, Inkscape, Gwibber, Mailman, GNOME Do and Launchpad itself. You can easily create your own as well by simply adding a hats/project-name/tools.xml file under your explorer configuration directory (e.g. ~/.bazaar/explorer). Here’s a sample tools.xml file:


<folder title="Tools">
<separator/>
<folder title="QBzr Development">
<toolset name="lp-devel" project="qbzr" />
</folder>
</folder>

It might just be me but I find project-specific tools mega cool: fast access to the places I need to visit, anytime I’m working on a particular project. Explorer is and will remain an easy-to-use GUI application suitable for casual users of version control. My grand vision though is for it to evolve into a collaboration-centric, BYO editor IDE, suitable for hard-code developers like myself to spend most of their day in. Keeping the easy-vs-powerful balance right won’t be easy but I’m confident we can do it. Give it a try and let us know how it works for you!

Bazaar adoption growing strongly

I’ve been tracking the popularity of the leading VCS tools on Ubuntu for the last 4-5 months using popcon. While popcon is far from perfect, I feel the results are a useful data point, given the popularity of Linux among software developers and Ubuntu among Linux distributions.

Here are the summary results.

Tool	19-Oct-2009	15-Feb-2010	Growth
Subversion	247760	282789	14.1%
Git	77791	94441	21.3%
Mercurial	28271	36086	27.5%
Bazaar	39391	51667	31.0%

As expected, all 3 major DVCS tools are growing faster than Subversion in percentage terms. What’s more interesting to me is that Bazaar and Mercurial are growing faster than Git, despite the buzz Git is currently enjoying. As a Bazaar developer, that’s truly awesome news.

Why do I say that? Looking back over technology trends, clean-and-simple products frequently lose the early battle against faster-but-more-complex competitors, e.g. Python vs Perl, GNOME vs KDE. Eventually though, the less complex tools become fast enough and powerful enough to satisfy most needs and their adoption takes off. That’s not to say tools like Perl and KDE are bad. I love them both but find myself using Python and GNOME more frequently these days. In the DVCS marketplace, I’ve always expected Bazaar (and Mercurial) to eventually grow faster than Git. I’m just ecstatic that it seems to be happening already.

gwibber developers on Launchpad and Bazaar

Review of Launchpad and Bazaar on ArsTechnica by the lead developer of gwibber.

• Likes the way the bzr client feeds into the web ui, by setting bug links etc
• Easy automatic imports from cvs, svn, git and hg, either for a one-shot cutover or continuing tracking
• More powerful bug tracking than github
• Loggerhead feels slow and poorly integrated with Launchpad, but qbzr is brilliant
• Merge proposals good for tracking contributions