Canonical Voices

Martin Pool

congratulations, Jelmer

I’m enormously pleased to announce that Jelmer Vernooij will be joining the bzr team at Canonical on a full-time basis from January next year, replacing Robert Collins (who recently became Launchpad’s technical architect). Jelmer has contributed to Bazaar over many years including driving the svn and git foreign branch plugins and the bzr-rewrite plugin.

Jelmer already works at Canonical on the Launchpad team, and has recently been involved with the recipe builds feature that automatically assembles deb packages from the contents of upstream branches. We will very likely look to hire someone to replace Jelmer on the Launchpad team, through the Canonical jobs page.

I got a lot of very good applications from the bzr community and beyond, and I just wish I could work full time with more of you. Thanks to everyone who did apply.

Read more
Martin Pool

A nice mail from Martitza this morning:

Hi.  Some of you may recall that I’ve provided measurements of some slow operations in both bzr itself and bzr-explorer based on bzrlib 2.1 and earlier.  I don’t recall doing any testing on bzr 2.2.0 specifically, but now that I’m on bzr 2.2.1 bzr (and bzr-explorer) are noticeably faster and even more pleasant to use now.   So far it seems that each of the add/commit/status operations on sets of 10K+ files (500MB+ branches) takes no more than two or three minutes each.  This is twice as fast as some of my previous measurements on the same or smaller branches.  Also, memory consumption is much reduced, which I suspect helps a lot.  I even have one of these large repos hosted on an old 512MB Pentium 3 machine with no problem today.  This is wonderful!  I hesitate to name the people I know made this possible, because I do not want to leave out the many more people whose contributions I don’t know.  Please accept my thanks to the whole team.

Read more
Martin Pool

I’ve worked with Robert Collins for the last 5 years or so at Canonical, and it’s been a real pleasure. Now Robert’s moving on to a great new rôle at Canonical, as technical architect of Launchpad. I can’t think of a better job for him, or a better person for the role, and it’s already paying off through Launchpad becoming faster (shorter page timeouts and hitting them less often) and I think more fun to work on. (See also his stump speech.)

Now we’re looking for a very good software engineer to join the Bazaar team at Canonical, working both on the core tool itself and on how it’s used by Ubuntu developers. We would love to get more applications from people with packaging or distro experience. I want to work with someone who’s very driven, who’ll reach out to their users and not wait to be told what to do, someone who knows the whole environment we work in, and someone who cares about doing good things.

Read more
Martin Pool

At the moment bzr treats deletion of a directory containing unversioned files (either ignored or unknown) as a conflict.

This is a bit annoying because often the unversioned files are generated trash, like .pyc files from Python. However in some cases people do have “precious” files that are ignored but shouldn’t be just deleted.

Vincent has a merge proposal up that will instead move the files into a bzr-orphans directory in the root of the tree.

What would you like to have happen? My feeling is that there should be a configuration option to choose the policy, and we should perhaps eventually distinguish “junk” (safe to delete) from “precious”, as Baz and GNU Arch did.

Read more
Martin Pool

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]

Ian Clatworthy 1966-2010

Read more
Martin Pool

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.

Read more
Martin Pool

?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.

Read more
Martin Pool

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.

Read more
Martin Pool

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.

Read more
Martin Pool

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?

Read more
Ian Clatworthy

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 Toolbox

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).

Servers for bzr

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

Docs for bzr

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">
<folder title="QBzr Development">
<toolset name="lp-devel" project="qbzr" />

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!

Read more
Ian Clatworthy

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.

Read more
Martin Pool

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

Read more
Martin Pool

Bazaar 2.1, coming through

[I tried before to describe everything; it was too long.  Take two.]

Bazaar 2.1 is going to feature-freeze later this week and release next month.  We’ll support 2.1 with bugfix updates for at least a year, perhaps more.  2.1 has over 200 bug fixes and incremental improvements (see the release notes), and a mostly-new system adminstrator’s guide.  Memory usage for many operations has halved, and John released off the Meliae Python memory profiler that he built while doing this.

Much of the feature innovation happened in plugins including (Explorer, Pipeline, builddeb and bzr-colo) rather than the core, which perhaps is as it should be for an increasingly mature product. We now have a kind of Good Food Guide(tm) for bzr plugins.

I like what we’ve done, but beyond 2.1 it would be nice to do a larger headline feature, as well as incremental fixes. On the Canonical side it’s going to largely go by feedback from Ubuntu developers as they use Bazaar more widely.

Read more
Martin Pool

TortoiseBzr (integration into the Microsoft Windows shell) is now being internationalized, with Japanese and Spanish translations now almost complete.

If you speak any language other than English, you can help with translation.

Read more
Martin Pool

Bryce writes:

When Inkscape moved to Launchpad, the Bazaar team asked if Inkscape would be adopting bzr as well.

With the Inkscape 0.47 release out, and following a rather lengthy series of debates on git vs. bzr vs svn, we have switched to Bazaar. Thanks go to Ted Gould for doing all the heavy lifting in shifting things over (and winning many hearts and minds).

From the Inkscape 0.47 release manager just now:

<ScislaC> I LOVE bazaar! :D

Finally a vcs I can use via command line in a way that makes sense to me and I don’t feel like I’ll accidentally make a bad commit.

Read more
Ian Clatworthy

One of the primary reasons why Bazaar exists is that Canonical wants to make it as easy as possible for more people to contribute to FOSS (Free and Open Source Software) projects. After many years of development, the pieces of the puzzle are really falling into place nicely. See the tutorial I put together last week to see just how easy it can be.

Read more

Naoki INADA recently provided nice patch for QBzr which added handy encoding selector to QBzr windows where content of user files is shown, including diff viewer (qdiff command), annotation viewer (qannotate command) and file content viewer (qcat and  qviewer commands). This feature is in the trunk now and will be released with QBzr 0.17.

This is very useful feature for all who works with non-ascii documents. By default QBzr assumes that encoding of your document is UTF-8, and this is safe default for Linux users. Unfortunately on Windows documents typically created in ANSI encoding (e.g. CP1251 for Russian, CP1252 for Western Europe, and so on). So having the way to specify encoding to see your actual text instead of $%^&#@&* garbage is very important.

So now you can control the encoding not only from command-line (option --encoding) but from GUI as well. Encoding selector(s) available at the bottom of dialogs as combobox. Such encoding selector is very important for users of TortoiseBzr and Bazaar-Explorer, because they’re using QBzr dialogs from corresponding GUI applications.

Diff viewer:

qdiff window with encoding selector at bottom


qannotate window with encoding selector

Selected encoding is remembered and saved in branch configuration file branch.conf as encoding = xxx.

Hint: if you most of the time working with files of one encoding, you can put the encoding setting in main configuration file bazaar.conf:

email = Joe Random <>
encoding = cp1251

And this settings will be used by default for all branches where no encoding specified in command-line or branch.conf.

Read more
Martin Pool

Neil started on a System Administrator’s Guide for Bazaar. The current text is here and it’s in the lp:~nmb/bzr/admin-guide branch.

Read more
Martin Pool

Patch Pilots

We’ve just started a patch pilot project in Bazaar, to make sure that patches aren’t lost in the noise, or stalled waiting for cleanups or tests to be added. In particular, we care a lot about testing for Bazaar, and testing well, but adding good tests can be harder than just making a two-line change that seems to fix the problem.

Andrew’s just finished the first stint as pilot, with good results: several patches landed, and people apparently having an easier time getting them.

I wonder how it will go? Will we keep finding the time to prioritize pilotage, and will there be positive feedback from contributors?

Read more