Posts tagged 'launchpad'

Last day at Canonical

meta = {'category': misc, 'date': Wed 17 October 2012}

This Friday will be my last day at Canonical.

It has been a lot of fun working here. There is so much I have learned in the last three years. I’m going to miss my colleagues.

Over the last couple of months I have slowly stepped down from my involvement in Bazaar and the Bazaar packaging in Debian and Ubuntu. I would like to stay involved in Ubuntu, but we will see how that goes.

I’m taking some time off until the end of the year to see the world and hack, before starting something new in February.

comments.

libapache2-mod-bzr

meta = {'category': bazaar, 'date': Sun 02 January 2011}

During the last two days I hacked together a Bazaar module for Apache. This module makes it possible to easily enable the Bazaar smart server for Bazaar branches. It also can display a simple placeholder page for Bazaar branches without working tree. It’s surprisingly easy to write Apache modules.

The main advantage this has over a mod_wsgi / mod_python / mod_fcgi setup is that it doesn’t require any additional Python hacking on the users side or other configuration outside of Apache, and it doesn’t require configuration for each single branch in the Apache configuration. In the future I’d also like to support the settings “BazaarFrontend Wikkid” and “BazaarFrontend Loggerhead“.

The configuration is currently as simple as:

LoadModule bzr_module /usr/lib/apache2/modules/mod_bzr.so
BazaarSmart on
BazaarFrontend Basic

in your apache2.conf. The BazaarSmart and BazaarFrontend directives can appear in <Directory> or <Location> clauses as well, if you’d like to have different behaviour for different directories.

At the moment this project is a proof of concept, and probably not something you would want to run in production. For example, there is no way to limit the access to a branch to read only. I need to double-check there are no threading issues.

Testing and patches are welcome. The project is hosted here:

https://launchpad.net/apache-bzr

Currently Playing: Stream of Passion - Calliopeia

comments.

Samba 4 and OpenChange daily Ubuntu packages

meta = {'category': debian, 'date': Tue 28 September 2010}

Daily builds

As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and OpenChange, built on a daily basis day from the latest upstream revision.

This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding.

OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make).

I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu.

As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises.

As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.

Recipes

The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:

# bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr{revno}~ppa{revno:packaging}+{revno:debian}
lp:samba
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick

This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build.

Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I’ve set it up.

For more information on creating source package recipes, see getting started.

Toolchain

The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It’s exciting to see everything come together.

Soyuz

Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.

Launchpad-code

Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API’s. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar.

Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git imports and Subversion imports left.

bzr-git and dulwich

bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and myself, almost two dozen other people have contributed it so far.

bzr-svn and subvertpy

bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds

To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:

$ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds

Currently Playing: Karnivool - Themata

comments.

Working from home

meta = {'category': misc, 'date': Fri 25 June 2010}

For about 6 months now I’ve been working for Canonical on the Soyuz component of Launchpad. Like most other engineers at Canonical I don’t work at the office but from a desk at home, as our nearest office is in London, not really a distance that is feasible for a commute. I do work at regular hours during work days and stay in touch with my colleagues using IRC and voice over IP.

I did have some experience working on contracts and study assignments from home previously, but working a fulltime regular job has turned out to be a bigger challenge. It seems easy enough. No travel time, every day is casual Friday, being able to listen to obscure death metal all day without driving coworkers crazy. Awesome, right?

Well, not entirely. I can’t say I wasn’t warned beforehand (I was) but I still ran head-first into some of the common mistakes.

Solitude

I can work well by myself and I appreciate the occasional solitude, but it does get kinda lonely when you’re physically sitting by yourself for 8 hours a day, five days a week.

Fortunately we regularly have sprints at different locations around the world and, apart from appealing to the travel junkie in me, that brings some essential face time with coworkers. Electronic communication mechanisms such as mailing lists, IRC, Skype and, more recently, mumble also help make the rest of the company feel closer, but it’s still very different from being able to talk to people at the water cooler (the point of which, btw, still escapes me. What’s wrong with proper cold tap water?).

What also seems to help is going into the city and meeting up with others for lunch, or even just to get groceries.

Concentration, work times

One of the nice things about working at home is that you’re quite flexible in planning your days; it’s possible to interrupt work to run an errand if necessary. The downside of it is that it is also really easy to get distracted, and there’s something I do very well: procrastinating. I initially ended up getting distracted quite often and then would end up working into the evening to make up for that lost time. The result being that, while only spending 8 hours doing actual work, it felt like having been at work for 12 hours in the end and having lost all spare time. Or as a friend summarized it accurately: working at home is all about boundaries.

This is at least partially related to the fact that I am a compulsive multi-tasker; I always do several things at once and context-switch every minute or so (prompted by e.g. having to wait for code to compile), including checking email and responding to conversations on IRC and Google Talk. This, among other things, has the effect that I respond quite slowly in IRC/IM conversations; if you’ve ever chatted with me you’ve probably noticed it. Multi-tasking has always worked well for me - despite research suggesting otherwise - because software development always involves a lot of waiting (for vcses, compilers, testsuites, …).

Recently I’ve tried to eliminate some of the other distractions by signing out off Skype, Empathy (Google Talk, MSN, etc) and Google reader completely and only checking email a couple of times per day.

Feeling productive

What has perhaps surprised me most of all was how essential the satisfaction of getting something done is. After spending about a day staring at Python code it’s important for your mood to have accomplished something. This appears to be a vicious circle, as lack of progress kills the fun of work, which kills motivation, which causes a lack of progress.

I am hard core, so during my first months I used my lunch breaks and evenings to hack on other free software projects, triaging bug reports that had come in or reviewing patches. Despite the fact that this is indeed technically a break from Launchpad, it didn’t (surprise!) seem to work as well as stepping away from the computer completely. Also, it turns out that spending 14 hours a day programming doesn’t make you all that much more productive than working a couple of hours less.

What I’ve discovered recently is that getting at least one branch done by the end of each day, even if it’s just by fixing a trivial bug, helps tremendously in giving me some sense of accomplishment. Julian also wrote a blog post with some useful hints on feeling productive a while ago.

What is your experience working from home? Any good tips?

Currently Playing: Sieges Even - Unbreakable

comments.

Linux.Conf.Au 2010 - Day 2 - Tuesday

meta = {'category': misc, 'date': Wed 03 February 2010}

On Tuesday we had our “Launchpad” mini-conf, which featured talks from Launchpad developers and users alike. It wasn’t necessarily about hosting projects on Launchpad, but rather about how various projects could benefit from Launchpad.

I popped out of the Launchpad track for a bit to attend Andrews talk about the current status of Samba 4. He did a nice job of summarizing the events in the last year, the most of import one of course being the support for DC synchronization. I’m proud we’ve finally managed to pull this off - and hopefully we’ll actually have a beta out next year. We have been saying “maybe next year” for almost 4 years now when people asked us for estimates of a release date.

At the end of the day Aaron and I gave a quick introduction to Launchpad’s code imports and code reviews.

comments.

Linux.Conf.Au 2010 - Day 1

meta = {'category': misc, 'date': Wed 03 February 2010}

Linux.Conf.Au has a reputation for being one of the best FLOSS conferences in the world, and it more than lived up to my high expectations. The last one I attended was also in New Zealand, but further south - in Dunedin.

Day 1 - Monday

As usual the actual conference was preceded by two days of miniconfs. On the first day I attended some of the talks in the Open Languages track.

mwhudson gave a talk about pypy - Python implemented in Python. He discussed the reasons for doing what they do and the progress they’ve made so far. Like so many of the custom Python implementations, one of the main things that’s holding them back is the lack of support for the extensions written in C for CPython.

Rusty gave a quick tutorial to talloc after lunch (“it’s a shame K&R didn’t think of this!”) and explained why it’s so great.

In the afternoon I caught some of the talks in the distro summit track. Both of the sessions that I attended happened to be Ubuntu-related - first Dustin gave a quick introduction to the components of Launchpad, followed by a talk from Lucas about the relationship between Ubuntu and Debian. There was a discussion afterwards about interoperability between the various hosting sites and bug trackers. Several audience members questioned the relevance of Debian and suggested everything should just switch to Launchpad, but this seemed to be founded in ignorance. (For the record, none were actually Launchpad developers).

comments.

Build from branch

meta = {'category': misc, 'date': Mon 01 February 2010}

At the moment I am returning home after three very productive and awesome weeks in Wellington, Sydney and Strasbourg.

I spent the first week in the West Plaza in Wellington, working together with fellow Launchpad developers on getting the basics of building from branches working. We eventually managed to get something working at the end of Friday afternoon. We split the work up at the beginning of the week and then worked on it in pairs for a couple of days before integrating all work on Friday. At the end of the week William managed to get a basic source package build from recipe through the queue.

Pair-programming with Jono and Michael was very educational, I suspect I’ll be a fair bit quicker when I get back to hacking on Launchpad by myself. It’s scary to see how some people can make the changes that would take me a full day in a mere hour.

Tim picked up my initial work on support for Mercurial imports and completed and landed it during the sprint. Since the rollout on Wednesday it is possible to request Mercurial imports on Launchpad. Most imports (e.g. mutt, dovecot, hg) seem to work fine, with the main exception being the really large Mercurial repositories such as OpenOffice.org and OpenJDK. This is because of (known) scaling issues that will be fixed in one of the next releases of bzr-hg.

This was the first time I was back in Wellington since 2006, and the weather this year was exactly as I remembered it; showers and wind, with the occasional day of sunshine. For a capital the city centre is quite small, but it has its charm and the view from the various hills around the bay is amazing.

On the weekend I met up with Andrew and Kirsty and we did some hiking around Wellington (where the weather allowed it).

comments.

My first week as a Launchpad developer: impressions

meta = {'category': misc, 'date': Thu 10 December 2009}

Roughly a week ago I joined Julian, Muharem and Michael, working on the Soyuz component of Launchpad. For now I’ve been working on easy Soyuz bugs, as a way of becoming more familiar with the internals. I’m working from home but I had the chance to hang out with some of the other Launchpad developers, including the full Soyuz team, at UDS Lucid in Dallas.

Launchpad is different from most other FOSS projects I have worked on so far. Some things I noticed during my first week:

The codebase is big and well tied together. I don’t think I’ve ever used grep and ctags as often as I have in the last week. Fortunately, the directory structure makes it relatively easy to predict where to look for things.

Reviews are really quick - no long round-trips between author and reviewer trying to get a branch landed. This is a really really great thing.

It’s easy to find somebody familiar with a particular piece of code and it doesn’t take long to get an answer when you ask questions. I’m still getting used to this - I tend to ask questions sporadically because I have gotten used to having to wait a couple of days for an answer that’s actually useful.

Setting up the development environment takes some time. Or perhaps I’m spoiled by Bazaar where “bzr branch lp:bzr bzr && ./bzr/bzr selftest” is all you need to start hacking. And it seems like karmic is the only platform on which things work - I tried with Debian Sid and Lucid as well, but things broke in strange and unusual ways.

The test suite is heavy and takes long to start up, something that makes proper TDD too hard. I also managed to run into some unexplainable problems where the librarian wouldn’t shut down on one of my systems. Since there is only one instance of the database it is not really possible to run multiple instances of the testsuite at the same time unless you use chroots or something like that - this makes it hard to work on multiple branches at the same time, something which would especially be nice since the testsuite is slow (so you can run the testsuite in one branch, hack in another and alterate).

Doctests, while fast, a bit of a nuisance. Because of the setup/teardown overhead that is paid for every single test, doc tests are a lot faster than unit tests. On the other hand, pdb doesn’t play well with doc tests - it doesn’t show any context. Conceptually I also prefer small unit tests over doc tests, since they’re quicker to read, easier to understand and there’s less side-effects from previous instructions in the test that could affect the code that’s being tested.

And for those that know me well; yes, getting used to somewhat regular working hours was indeed a challenge, but I seem to have managed.

comments.

Page 1 / 1