This was quite timely as my team has been thinking about improving the process of creating our release notes, and it has been proposed that we generate them automatically from our commit messages. This in turn requires that we have commit messages of sufficient quality, which – to be honest – we don’t always. So the second proposal is to enforce “good” commit messages as part of reviewing and approving merge proposals into our projects. See this post from Kevin on my team for an overview of our branching strategies to get an idea of how our projects are structured.

We still need to define what constitutes a “good” message, but we will certainly use both the article from Thoughtbot and the oft-referenced advice from Tim Pope as our basis. We are also only planning to apply this to commits to trunk because, well, you don’t need a novel – or even a short story – for every commit in your spike branch!

Now, back to the Thoughtbot article, and this piece of advice stood out for me:

Never use the -m <msg> / --message=<msg> flag to git commit.

Since I first discovered -m I have used it almost exclusively, thinking I’m being so clever and efficient, but in reality I’ve been restricting what I could say to what felt “right” on an 80 character terminal. If nothing else, I will be trying to avoid the use of -m from now on.

While a lot of you are at UDS, several Latin American LoCos are working hard to organize a local Ubuntu conference.
Things are going really well, we're 4 weeks away, but we're a little short on funds. Every year the same people who organize it end up having to pay for many things themselves despite have a few generous sponsors, and this year I'd like to change it so I set up a small but valuable fund raising campaign and we could really use your help.
The site is in Spanish, so it may take a bit of blind surfing to get around but it should be fairly easy once you've been sent to PayPal

We’ve just upgraded Launchpad’s builder machines to Bazaar 2.4. Most importantly, this means that recipe builds of very large trees will work reliably, such as the daily builds of the Linaro ARM-optimized gcc. (This was bug 746822 in Launchpad).

We are going to do some further rollouts over the next week to improve supportability of recipe builds, support building non-native packages, handle muiltiarch package dependencies, improve the buildd deployment story etc.

Making Ubuntu a Target for App Developers

Jono, who has recently started working on the Ubuntu developer programme after having been developing and defining the strategy on Launchpad for the last 5 years, started off explaining that to cross the chasm and to get our OS from 20 million to 200 million users, we need more and better apps on Ubuntu. There are some key aspects to this goal, coinciding with areas of ongoing work:

A place – making some place that app developers can go to in order to learn how to develop for Ubuntu (developer.ubuntu.com)

A definition – defining a platform for developers to target

A channel – a smooth, short, safe path from developers to their users and back again (the Ubuntu Software Centre and MyApps)

After expanding on the subjects of automatic packaging and security, the conclusion is that with all of these pieces in place -Software Centre, developer portal, a defined platform, automagic packaging, safe mechanisms for distributing new apps & paying developers- then Ubuntu becomes something that developers can seriously start to target

Introducing Bazaar Explorer: Version Control for your Apps

“Bazaar is the world’s finest revision control system” – an awesome quote to start an equally awesome session. With this, and with the idea that Bazaar needs to be available to anyone, not only to those already comfortable with the command line, Jonathan Riddell provided a tour of the most feature-rich GUI for Bazaar. Illustrating the most common commands for everyday use and with plenty of pictures, he provided an excellent overview of how this powerful, cross-platform, graphical interface for bzr can make life much easier to app developers.

Your App & Launchpad best practices

Jason’s session on how to make the best use of Launchpad, the online collaboration and hosting suite for your projects, was structured around 3 central points: 1. Why should you host your project in Launchpad? To which his answer was: because PPAs, daily builds and lots of users; 2. How to set up your app to use Launchpad, where he guided participants through the process of creating a Launchpad project and offering some insights on best practices. Finally, on 3. Using Launchpad to engage developers he wrapped up with a series of recommendations and tips to ease and foster contributions to your project. More on the session log

Getting Started With Python: a Hello World App

As a grand finale to the day, Alan delivered a beginner-friendly session on the basics of the Python programming language. Assuming no prior knowledge, he walked participants through the classical “Hello world” example in Python, which universally greets programming novices on the terminal with a friendly welcome message. Along the way, he explained in detail all the extra bits to make this simple application run and be useful as a kickstart to becoming a full-blown Python programmer.

The Day Ahead: Upcoming Sessions for Day 2

Did you know that along with code hosting, release management, bug tracking and support, you can also use Launchpad to get your app translated?. David Planella will explain you how to set up your app in Launchpad for translations and give you some advice on building a translator community around it.

Unity needs to run on every type of desktop, from those with powerful 3D graphics processors to those only able to run in 2D. Unity 2D was born out of the need to provide a near identical experience as its 3D counterpart on systems which cannot rely on 3D graphical processing, such as ARM computers. Florian Boucault will talk about what Unity 2D is, how it was designed, and the technologies used to implement it.

Gedit is Ubuntu’s lightweight yet powerful default text editor. Its flexible plugin architecture means that it can easily be extended to meet any need. Curtis Hovey will guide you through his Gedit Developer Plugins to help you convert a general-purpose editor into the perfect programming editor.

Canonical is taking app developers very seriously,and one of the important aspects of ensuring a smooth workflow for submitting and publishing applications into the Ubuntu Software Centre is providing the right set of tools. Anthony Lenton will tell you the story behind the MyApps tool and how app authors can use it to submit their apps.

If you are an open source developer and want to publish your libre + gratis app into the Ubuntu Software Centre, the App Review Board (ARB) will take care of reviewing it, ensuring it is up to the Ubuntu standards and help you publishing it for all users to install. Stéphane Graber is a member of the ARB and will explain how the Board works and the steps to successfully submit an app for review.

As I'm sure most of you are aware, Launchpad hosts Bazaar branches. One early design decision that we had on Launchpad was that branches should be able to be renamed, moved between people and projects without limitation. This is one reason why each branch that was pushed to Launchpad had a complete history. We wanted to make sure that there weren't any problems where one person was blocking another pushing branches, or that people weren't able to get at revisions that they shouldn't be able to.

The Bazaar library, bzrlib, gives you awesome power to manipulate the internals giving you access to the repository of revisions through the branch. This can be a blessing and a curse, as if you have private revisions, then they can't be in a public repository.

Having a complete copy of the data for every branch became a severe limitation, especially for larger projects, of which Launchpad itself is one. A solution to this was a change in Bazaar itself that allowed a fallback repository which contained some of the revisions. This is what we call stacked branches. The repository for the branch on Launchpad has a fallback to another repository, which is linked to a different Launchpad branch. We ideally wanted all of this to be entirely transparent to the users of Launchpad. What it means is that when you are pushing a new branch to Launchpad, the bzr client asks for a stacked location. If there is a development focus branch specified for the project, this is then offered back to the client. The new branch then only adds revisions to its repository that don't exist in the development focus branch's repository. This makes for faster pushes, and smaller server side repositories.

The problem though was what do we specify the stacked on location to be? When we created the feature, we used absolute paths from the transport root. What the mean was that we stored the path aspect of the branch. For example, lp:wikkid gets translated to bzr+ssh://bazaar.launchpad.net/~wikkid/wikkid/trunk or http://bazaar.launchpad.net/~wikkid/wikkid/trunk depending on whether the bzr client knows your Launchpad id. The absolute path stored would be /~wikkid/wikkid/trunk. This information was then stored in the branch data on the file system.

The problem however was that the web interface allows you to rename branches. The actual branch itself on disk is referred to using a database id, which is hidden from the user using a virtual file system which has rewrite rules for http and at the bazaar transport level. However since the stacked on location refers to a full branch path, changing any part of that, whether it is the branch owner, branch name, or the project or package that the branch is for, would cause any branches stacked on that changed branch to break, bug 377519.

In order to fix this we had to change the location that the branch is stacked on to be independent of the branch path. The best solution here is to use the database id. I really didn't want to expose the user to this opaque id, but one opaque id is as good as another. Now when pushing branches to Launchpad, when it is creating a stacked branch you'll see a message like:

Created new stacked branch referring to /+branch-id/317141.

Existing branches still have their old branch paths saved for now. We'll run a migration script early next week to fix all these up, and hopefully we'll have seen the last of this bug.

I have to confess, after I heard I found out we where shipping Unity in Ubuntu by default I was nervous. I got asked many times what my feelings were, and I think I generally dodged the question. This was a pretty risky move, which we are still a few months away from finding out how well the risk pays off.
Given that a lot of the design behind Unity wasn't done in the open and hadn't had a long time to mature, I've been sceptical of whether we (as in, the Ubuntu project) could pull of such a massive change in a such a short period of time, and still have happy users.

I've been using Unity on and off on my netbook (which is my secondary computer), but while enjoying a long weekend I've spent the last few days using it a lot, and my feeling towards the it have changed quite a bit.

I think it was the right decision. Overall, it feels like an overall improved experience, even with its current rough edges. Exactly what I think we need to win over a wider audience and have them fall in love with Ubuntu head over heels. Everything is starting to feel much more tightly integrated and with a purpose, as well as some eye-candy sprinkled in a lot of the right places.
I'm really glad Canonical decided to invest to heavily in such a risky and insanely complicated task, Natty is probably one of the most exciting releases I can remember.

There are still a few key challenges ahead, most notably to me is making the design process more open and inclusive, but still being able to deliver something that feels polished and not a pile of consensus between people who have gotten good at arguing. The Ayatana community does seem to be slowly growing, though, so the future looks pretty bright. Getting the right balance between Canonical and a community around design feels like one of the hardest problems to solve, luckily, Canonical continues to hire the brightest and most enthusiastic minds around, so I'm sure it will eventually feel like a solved problem.

I think it's been almost 6 years since I landed in the Ubuntu world, I've done all kinds of things in the community ranging from starting and building the Argentine LoCo to editing the Ubuntu Weekly Newsletter, to evaluating new Ubuntu members in the Americas region. With its ups and down, great press and wild controversies, it still feels like the best place to be.

One of the questions that took a little while for me to fully understand was a very simple one: why does Ubuntu One exist?

Depending on who you ask, you may get a different answer, but here's my take on it.

Above all, to extend the power of Ubuntu as an environment. Ubuntu One already allows you to many things beyond the basic file sync we started off with, you can keep your contacts from your phone and desktop (and between other Ubuntu devices) in sync and backed up, notes, bookmarks, all your important files are backed up and synced, you can share them privately or publicly, you can buy music that gets delivered right to your music player, and soon you will be able to stream any of your music to your phone. And this is just today. As the project matures, we are working hard to make it easy for more and more third-party projects to use our platform and out-pace us in ideas and code.
All of this allows Ubuntu to extend its reach into mobile devices and even other operating systems. It feels like integrating into the real world today, not only the world we want to build.

Openness is the next thing on my mind. I know about all the criticisms about the server software not being open, I understand them and I've been through this same process with Launchpad. Right now, Canonical doesn't see a way to fund a 30+ developer team of rockstars, a huge infrastructure and bandwidth usage that is mostly used at no cost and still offer up the code to any competitor who could set up a competing project within minutes. I am sure someday, just like with Launchpad, we will figure it out and I will see all my commits push me up thousands of positions on ohloh. Until then, I'll have to continue working on Wikkid or any of the other 20 projects I use and am interested in, to keep me at a decent ranking.
All that said, the Ubuntu One team releases tons of source code all the time. A lot of the libraries we build are open sourced as soon as we get some time to clean them up and split it out of our source tree. All our desktop clients are open source from the start. On top of that, we work on pieces like desktopcouch, enabling couchdb for the desktop. We even got the chance to work with a closed-source iphone application, iSub, to open source his code so we could base our new streaming client on. We get to pay developers of open source projects on the Android platform as well, to work on improving it so we can deliver a better and more secure experience. We also get a chance to learn to package applications and upload new versions of the libraries we use to the Ubuntu repositories. And hundreds of other small things we do that feel so natural we forget to advertise and be proud of. All of this on Canonical's dime.

Finally, a goal that is dear to my heart. Make Canonical profitable. I have been overwhelmed over and over again by the passion with which Mark personally, and the company as a whole, contributes to making open source be the standard way of developing software in the world. I can understand why it's easy to feel uncomfortable with a privately owned company pursuing a profit while sponsoring an open source project which thousands of people contribute to, but after having sat down in dozens of meetings where everybody there cared about making sure we continue to grow as a community and that open source continues to win over tens of thousands of computers each month, I only worry about Canonical *not* being sustainable and constantly growing.

All these reasons for working on Ubuntu One have been close to my heart for many years now, a long time before I took the final step of investing not only my free time, but my work time, leisure time, and not too seldom, my sleep time, and started working for Canonical in a very strict sense of the term "full time".

I've spent time working in a few different teams, all of them are interesting, exceptionally skilled and open source is a core part of their lives. Ubuntu One is where I feel I can do the most impact today, and I'm beyond lucky to have given the opportunity to act on it.

For the first year and a half in Canonical I worked with the amazing Launchpad team, with the ambitious goal of building a new user interface, introducing AJAX in an established code base and rolling it all out on time. While all of that was overwhelming in itself, what was more important to me was making sure the UI remained consistent across time.
Long story short, it was a success and it's been 8 months since I've left the team and the established process is still on-going.

When I started working with the Launchpad team I was tasked with designing and rolling out a new interface using cutting-edge technology on a well established product and team. The existing processes and team structure made it very hard to roll out big changes while also ensuring consistency as time went by.
While the general designs and work ow changes were being eshed out, I started to drive some change to the existing processes, enabling me to be successful at an objective that would take a year to accomplish, and unexpectedly, beyond that.
The project was 4 years old and had over 500 dynamic pages with different templates and layouts that had been left untouched at different points in time. The goal for the next year was to make the application easier to use, even enjoyable. I also had to make the UI consistent across the board, take the project from static HTML pages into the wonderful world of in-line editing, streamlined work-flows and predictable interactions. In parallel, fundamental features that had been developed were going completely unused and we needed to turn that around. A re-usable AJAX infrastructure had to be developed from the ground up, new features needed to be designed and delivered, and general navigation issues needed to be addressed.
However, this story isn't about the success of the roll out of a new interface, but rather the success in the process changes that evolved during that year and how the project went from nobody feeling ownership over the user interface, to the developers taking strong ownership.

I feel very passionate about this subject, and hope this experience can help other projects and teams.

We have very exciting and challenging plans for the future of the new web+mobile Ubuntu One team (more on this soon), and we’re looking for an exceptional web engineer to join us.

The summary for this position is:

We are looking for an exceptional engineer to work on Ubuntu One’s web infrastructure with a proven track record for exceptional problem solving and integration into third-party systems. This person should help the team design, build, and deploy web and mobile applications with a high degree of quality and passion. If you’re the type of person who gets excited about delivering cutting-edge technology to hundreds of thousands of users, in a lean and friendly environment, we are looking for you!

As with any creation being released, I'm writing this with some trepidation. I'd like to announce the first release, 0.1, of Wikkid Wiki.

What is it?

Wikkid is a wiki that uses the Bazaar DVCS as an underlying storage model. Wiki pages are text files in a branch.

Why another wiki, surely there are enough already?

There is the obvious reason, because I felt like it. But this is not the primary reason. Since I started working for Canonical I've come to appreciate the whole culture of free, libre, and open source software more. During the day I work on Launchpad. Primarily in the area of integrating the Bazaar DVCS. Launchpad doesn't have a wiki integrated, and it is my plan to see wikkid be the wiki that is integrated.

I have to admit to having very strong opinions myself on what I wanted for wikis in Launchpad. I've tried to encapsulate that in the vision below. Since no one else was looking at it, I took it upon myself. Discussions started last year between a small group of Launchpad developers, but there was no traction. At the start of March I started writing the Bazaar backed wiki. It needed a name though. Thankfully after trying several I got the perfect name from Aaron Bentley - wikkid.

The wikkid vision

Any wikkid wiki can be branched locally for off line editing.

Any branch can be viewed using wikkid - not limited to branches created through wikkid

A local wikkid server can be run using a Bazaar plugin

Local commits use the local users Bazaar identity

Wikkid can be configured to operate in a stand alone, public facing mode where it has a database of users

Wavesat is using the Bazaar version control system for commercial development making it simpler and easier for their teams to collaborate around the world. It’s a great example of Open Source delivering cost savings and innovation to business users. We’ve recently put up a case study that gives more details.

Bazaar (Bzr) is a distributed version control system. It’s an essential tool for developers: there’s a great guide to revision control on betterexplained.com. When people state that there’s no innovation in Open Source, distributed revision control is one of the examples that counters this.

Bazaar is particularly well suited to distributed development because the concept is built-in right from the start. Perhaps it’s testament to the open source development process which is by its nature distributed. For a business like Wavesat that has developers based in different locations this means they can be more efficient.

Canonical sponsors the development of Bazaar because distributed revision control is critical in Open Source development. But, it’s also something that companies can benefit from so we provide commercial services for Bazaar. This consists of helping organisations migrate, along with providing support and training. For organisations with an existing version control system such as CVS or Perforce we help with the migration to a new work-flow using Bazaar on Linux (Ubuntu, RHEL, SLES) or a legacy operating system such as Microsoft Windows or Apple Mac. Check out the case study for more information.

While we slowly ramp up to release mobile phone contact sync, using my own contacts as test data I realized that once I had merged my phone’s address book and Thunderbird’s address book, I had quite a few contacts duplicated due to them having different names with different information in them. So I had one of those “you know what would be cool…?” kind of moments, and started working on a feature that would let me merge contacts on the web, saving me hours of copy-n-paste.
A few weeks later, an initial pass at that feature has rolled out! Yay agile software development!

There are a few tweaks to the contacts interface, and you will see a new option:

So, for example, let’s pretend you have 2 contacts that are the same person but have an extra name in one of them, one of them has his phone number, the other, his email:

and

We go to our new merge feature and select both of them:

Finally, we get a preview of what this will look like:

Done!

Plans for the future are:

- Allow conflict resolution when the contact has 2 fields that are the same but have different values
- Allow editing the contact in the merge preview
- Allow merging from the contacts page instead of a separate page
- Use this same mechanism when conflicts arise in couchdb merging contacts
Also, contact syncing from thousands of mobile phones will be opened up for a public alpha very very very soon. Stay tuned!

Since the shelf plugin was moved into bzr core I've been missing a way to see the actual changes that I have shelved without having to unshelve them. Having waited long enough for someone else to implement it, I decided it was about time to do it myself.

With some help from jam, it was merged into bzr-2.1.0b1 and is now available in the bzr-nightly-ppa.

All projects in Canonical have a strong focus on testing. From all of them, I think Bazaar ranks the highest on obsesiveness on testing. As a drive-by contributor, it always felt like a very high entry barrier, and deterred me from getting into complicated changes. It was only after I bit the bullet and got into more complicated changes (in Launchpad, actually) that I understood that tests where my best friends ever. It’s a safety net against myself, and actually lowers the barrier, because I don’t need to know about the rest of the code base to make a change, tests will tell me if I break something (seemingly) unrelated.

On the more extreme side, there is test driven development (TDD). You write the tests first, watch them fail, and then start producing the code that will get them to pass. Having co-authored bzr-upload with the TDD-obsessed bzr developer, Vincent Ladeuil, I thought that if I was going to add a new feature, I may just as well try it (again).

It rocked.

I set up the test, my carrot, and the task went from “start poking around code” to “fix this problem”. With the test written, it became very clear what parts of the code I needed to change, and how the feature had to work.

During UDS Vincent and I made sure we shared a room so we could talk a bit about what we wanted for the future of bzr-upload.

To ensure we didn’t loose any of the conversation, he took notes and sent them to me, so now I’m passing them on for those of you interested in contributing or just knowing what features are in the pipeline.
* Create a .bzr-upload-ignore file that ignore any action for which one the paths matches an ignore regexp. Use the working tree version by default, fallback to the versioned one otherwise

* New command: “bzr upload-check”. Walk the remote site ensuring that every file still has the same content that the local version –restore optionally restore the remote content to the local value. Optionally for remote sites implementing ssh and providing an md5 binary, the check can be implemented by comparing the local and remote md5 avoiding the full downloads.

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.

Following up on my last post about user testing icons, it has been incredibly successful! We’ve had over 100 responses, and are now going through the data to put together a summary. I will post information on our findings as soon as we finish the work.

In the mean time, Charline Poirier, who is in charge of user testing in our team, has created another survey with 5 more icons to help us get more data. If everyone could give this survey another spin, and create some networking effects to help spread the survey to non-Launchpad users, it would be tremendously helpful to us. Here’s the link: http://www.surveymonkey.com/s.aspx?sm=6iwthaIT4FwPCsMPa1EDEA_3d_3d

We’re trying to improve the icons we have in Launchpad so they’re more usable across different cultures and types of users, and our first step is to do some user testing on our current icons.

The Canonical User Experience team has set up a survey to gather information on how users see our icons, so if you have a few spare minutes (it’s very quick!), please take the survey and pass it on to other people, especially if they don’t use Launchpad, as they will be less biased.

As promised, Launchpad has been fully open sourced (as opposed to the initial idea, nothing has been held back). Get it now, fix your favorite pet bug, and improve tens thousands of people’s experience.

Mark Shuttleworth really deserves a lot of praise for this bold and brave move, open sourcing not only the code, but all it’s history. It’s a fantastic day today.

Update: yes, fully means including soyuz and codehosting, Mark has decided to release everything. The whole history is there.