Why PyRoom chose Launchpad
Published by Matthew Revell March 4, 2009 in Projects
Perhaps shutting out the distractions of the physical world is no longer enough.
PyRoom is a simple text editor that shuts out all the distractions you might find in a more complex editor or word processor, giving you nothing but a black screen that you can type into.
Bruno Bord has driven the project and chose Launchpad to host it. I asked him what led him to choose Launchpad.
Short answer: Because I was lazy, and I didn’t want to hack on a project management system myself. Launchpad hosts everything I wanted: code, bugs, translations.
Long answer: It’s not just the bug tracker. It’s the whole thing. Bug trackers are very interesting to track down tasks, reorder them, assign them priorities, etc. But it’s like playing all alone on a video game while you could have much more fun playing it online, with other people
involved.I discovered Code Versioning System and then moved to Subversion, which was a massive improvement. When I had to download a source code from CVS, I used to copy-paste command lines I didn’t understand into a bash script, and run it from time to time to update my working copy. I’ve never used CVS as a committer, and I’m glad.
I was working in a small web agency where the “revision” system was just renaming the old version of a file/directory “_old”, make a copy of it, and go on with the developement. Of course, when there was another “revision” to “commit”, you had to rename it “_old2”. Hem. Pretty amazing how things can become hellish using that kind of system.
I heard about Subversion, and reading the docs, I instantly fell in love with the syntax. At last, I could version my work with commands I could grok!
I made a quick svn+trac install on our local server, and that was ready. One of the major drawbacks of Trac at the time was the impossibility to track several projects at once.
So I had to build up a trac instance for every new project. Which was fine, as soon as I could make a tiny bash script that did everything from the ground up (svn repository and trac setup).
Anyway. I started using SVN for my personal projects. A friend of mine accepted to host my trac+svn instance for pet projects on his personal web server, and everything was fine.
One day, I moved. And I went off the internet at home for 149 days. Yes. It’s a huge number of days for a geek. At work, it was ok, but it was impossible for me to commit changes about my pet projects.
After months of despair, I finally found out about Distributed Version Control. And bzr changed my life. I could work on my projects offline, commit code, branch, merge, etc, and push it back again in the main repository when internet connection came back — this is true for any DCVS, not only bzr…
But bzr isn’t very well integrated into Trac (yet). And it’s fully integrated with Launchpad.
What’s absolutely brilliant in Launchpad is the fact that any item may interact with another. You can register a branch in a project, or in your “+junk” repository, or you can link a bug to a branch or link a branch to a bug. Once the bug is fixed, you propose the branch for merging. You can build up teams, working on specific tasks on your project: bugsquad to sort out bugs, developers to commit in the main branches, translators, or a just more general team where people interested by the project can get notifcations at any time.
Hence, using LP as a project manager makes sense.
Using LP for PyRoom was an instant choice. When I retrieved the initial python script from ubuntuforums, I commited it into a bzr branch, hacked on it a bit to clean up the code, and pushed it on the fresh new project hosted on LP.
I learned a lot during the first weeks of the project: one of the best practises is to create teams. You are on your own at the beginning, but create a team anyway, and give this team read/write access to the trunk of the project. When people start to get involved, they join the team, and are granted instant access on the main branches of the project.
But the good thing with LP is that you don’t actually NEED to be part of the dev team to send code. For Gwibber, for example, I just hacked on a bug I found with my French locale the main developers couldn’t guess. I just registered a bug, created a branch, pushed my code to this branch, and proposed it for merging. It was merged without me being member of the Gwibber team or whatever. Now the bug may be closed. WIN!
My first contributions in LP were translations, IIRC (into French, what a surprise!). Again, I was not member of any team to translate small strings in my mother tongue.
You see… it’s not just the bug tracker. Any text editor can work as a bug tracker, as long as you keep your tasks up to date in a single file. It’s the whole shebang that rocks.
Translations team in Buenos Aires
Published by Matthew Revell in Translations
I’m in Buenos Aires this week with the Launchpad Translations team — Danilo, Jeroen and Henning — along with Launchpad UI guy Martin Albisetti.
We’re working on making Launchpad cleverer at giving people the information they need where they need it. Each day we’ve been sitting with a white board, a list of existing pages that we want to improve and one simple question: what do translators want from that page?
And that’s a question that we can answer through the feedback that we’ve had on how translation can work better and also the translations that we’ve made ourselves.
We’re half way through the week and have some great plans that you can expect to see in place before our 3.0 release in July.
Inside the Launchpad Foundations sprint
Published by Leonard Richardson March 3, 2009 in API
I’m in Montreal this week, with the rest of the Launchpad Foundations team and a few other Canonical engineers. We’re preparing for the open sourcing of Launchpad by doing a lot of refactoring, so that when the code is released in July it will be more comprehensible, and reusable in projects other than Launchpad.
In addition to our main body of Launchpad code we’ll be releasing a framework project called LAZR. Code that’s not Launchpad-related will go into LAZR or one of its subprojects: lazr.config, lazr.uri, lazr.batchnavigator, and so on. These will be little libraries that can be reused in other projects.
For instance: underneath the Launchpad web service is a generic library that lets you create a web service from your existing data objects by annotating the Zope interfaces. All this code lives in LAZR: the only web service code in Launchpad has to do with Launchpad’s web service specifically. We’d like you to reuse the LAZR webservice code in any project that uses Zope interfaces to describe its data objects.
Unfortunately, there’s a lot of code in Launchpad that really should be in LAZR. If that wasn’t bad enough, the web service code in LAZR is full of dependencies on that Launchpad code. At the moment, you can’t run the LAZR web service code without bringing in all of Launchpad.
The object of this sprint is to refactor this code and move it all into LAZR packages. Our medium-term goal is a working example web service (code name “Sharks”) that uses no Launchpad code, but it won’t stop there. The more utilities we can move out of Launchpad’s monolithic code base, the more likely it is you’ll be able to find a bit of code you want to reuse.
Meet Jeroen Vermeulen
Published by Matthew Revell February 27, 2009 in Meet the devs
Jeroen Vermeulen gives us our first Asian stop-off in the Meet the devs series.
Matthew: What do you do on the Launchpad team?
Jeroen: I work on the Translations application. That’s where we translate software (including all of Ubuntu’s “main” section!) from English into just about any language I’ve ever heard of. Many people still know it by its original name, Rosetta.
Matthew: Can we see something in Launchpad that you’ve worked on?
Jeroen: It’s a funny thing: that question makes me realize how little really “visible” stuff I’ve written. I’ve been working with the database a lot and of course fixed bugs. You could say there’s mostly things that you can’t see in Launchpad that I worked on.
Recently though I’ve been working on something you should see show up in more places soon: the inline text editor. If you have javascript enabled in your browser, you can already use the existing version when you edit a bug title. No need to click through to an editing form: you just click the “edit” icon and the title becomes editable in-place.
The version I’ve been working on together with Danilo Šegan (I found out how to type that weird letter by accident:
It’s been both fun and a nuisance, since JavaScript lets you do very powerful stuff very quickly… and then it lets you spend days debugging the silliest little things. It’s a far cry from the C++ work I’ve been doing in my spare time. There, all your weak typing happens at compile time. At run time it’s all strong typing with a tiny bit of polymorphism. So it’s usually the compiler that spots the bugs, not your tests per se. As the language matured we grew habits and practices to reinforce this. Nowadays I barely even use polymorphism anymore in C++: only in a handful of isolated patterns, and more often than not purely at compile time. As my friend Kirit Sælensminde puts it, it’s great to have a compiler as a theorem prover for your code’s correctness!
Matthew: Where do you work?
Jeroen: Mostly in Bangkok, Thailand. I like to poke fun at my colleagues in places that are 40°C colder.
Matthew: What can you see from your office window?
Jeroen: One of the reasons why I picked the place: some green, unused land! It’s got grass, trees, birds, and not a whole lot of noise. That’s pretty rare in this city. What there is is usually hidden behind walls.
Right under my window there’s a dirt road with a volleyball net strung across it. Sometimes the children have to stop playing and lift the net to let a car pass underneath.
Matthew: What did you do before working at Canonical?
Jeroen: I worked for a Thai government department set up to promote open-source software in the country. It was a good chance to learn, both about technology and about cultures.
Nothing shows how the two can interact as well as the questions I got at trade shows. For instance, many people believed that software you give away cannot possibly have any value. To those people I had to explain how the software made money for the companies behind them, or they just wouldn’t consider using it. This in a country where pirated proprietary software is the norm, and price-competitive with free downloads.
Other people thought that “open source” and “linux” were the same thing, and were very sceptical when you showed them free software running on Windows. Those who do work on free software, and we have some very enthusiastic people doing that, tend to be a bit too shy for the process. They are often reluctant to badger authors about accepting patches or translations. Translating Ubuntu in Launchpad is a great way for them to get around that.
Matthew: How did you get into free software?
Jeroen: Mainly by not staying out of it. When I started programming for fun in the early 1980s, the only reasons my friends and I ever saw not to share our code were embarrassment (if the code was ugly) or fear of someone passing it off as their own (if the code was pretty). But most of the credit goes to some great people I met in and after university, and a company called Cistron that got me working with 100% free software professionally.
I did work a few jobs involving proprietary software, and some of those left a very bad taste in my mouth. At Cistron we sometimes had to patch the software we used, because it wasn’t always mature. But at least we could, and we’d be helping the software mature in the process. We didn’t need to ask for permission, or wait for someone who already had our money to decide whether our problem was a priority. In the proprietary world you always had to beg or wait for permission to solve some problem or other.
Surprisingly often, it’s easier and cheaper to deal with a problem yourself than to go through the process of getting proprietary software licenses for it. That’s even before you start handing over money. If you do make it past that, you come to the stage where you start seeing the little gaps between what you bought and what you needed. And then you end up coding your own in-house glue anyway.
There was a lot of the code as well, under the glitzy surface. Oh, the code! Some examples I’ve seen:
- A button in a user interface switches the application between two modes. The button changes its label and its colour between modes. The business logic decides which mode it’s in by looking up the button’s current colour. Yes, you read that right. This is in a large-scale financial application. The code was then given to cheaper foreign engineers for maintenance, despite all the comments, identifiers etc. being in the local language and unreadable to the engineers. The maintenance was necessary because the application relied on some proprietary commercial infrastructure that was being end-of-lifed by its vendor.
- A database table has three consecutive rows for every logical item it describes. A loop searches them linearly instead of using SQL’s WHERE clause. Instead of using a meaningful marker, the loop computes what row #i represents by taking i % 3. The switch statement has cases for 0, 1, 2, and “default.” It’s been a while but I seem to remember there was a case for 3 as well.
- A database object cache looks if the object you requested is already in memory. It does so by taking the numeric id for the object you want and comparing it to each of the cached objects’ addresses. It never finds a match because in-memory addresses simply have nothing to do with identifiers in the database. The problem goes unnoticed for years (causing memory leaks and data loss) because the compiler, also proprietary, takes until version 5.0 to start noticing that this is a very basic type error.
It’s not like we don’t make those mistakes in free software. But we let people catch us at it, and it’s better for everyone. In fact I’m convinced that projects like Linux and MySQL became so popular in part because there were enough things for beginning contributors to fix.
Matthew: What’s more important? Principle or pragmatism?
Jeroen: You’re eating soup. The bowl breaks. (Not likely, but work with me here). Now tell me which was more important: the bowl or the soup?
I know a lot of people get very worked up about this. But principle and pragmatism are on a two-way street. Going one way, principle is where you look when deciding what you should do. Or, and this is usually what gets people worked up, what everyone should do. But going the other way, you look at pragmatic reality and discern all sorts of principles. That, I think, is the real attractor to the whole debate &mash; free software has basically revived classical philosophy. What you learn there, what catches your imagination, what patterns you see and choose to explore, is all very personal.
There are people like Eric Raymond who will say that everyone just does what’s in their best interest, and nothing else will decide the course of events. The big epiphany they take from the free/open-source development is game theory and how it applies to markets. Then there are people like Richard Stallman who see how the given incentives in the market pit us against each other, and decide that it’s a bad thing. They derive a field-specific model of morality. Personally I’m fascinated by both.
But enough weaseling: I’m more on the “principle” side, because I don’t think principles are inherently non-practical. One of the smartest people I’ve known once said that morality evolves. It grows and adapts to help us survive as a group, just like perspective vision or opposable thumbs. Software licensing is at a point where different people try different things and we’re seeing what works. If I “sell” you software, it has to be like a piece of property, except copying is free and unlimited. So should we pretend that the program is still “my property” after the sale, only I’m also letting you use it? Or is it now yours, except I can sell it to others as well? It’s a lot like the old particle-or-wave debate about the nature of light.
Matthew: Do you/have you contribute(d) to any free software projects?
Jeroen: In all sorts of ways, usually to scratch an itch: a patch here, some documentation there. My main project is libpqxx, the C++ client API to PostgreSQL. I worked with the old API back in 2000, and it was as if the right approach just jumped at me, shouting “code me, code me!” I get a lot of positive feedback about how it blends in with the language and its standard library.
Sometimes you can do more good by documenting than by coding. We engineers are all the same: once you understand something, it’s “obvious” and suddenly you’re unable to explain it. I thought D-Bus was a great development when I first saw it, but the documentation was thin on concepts and too detailed. Since I had to figure out the concepts anyway, I made a list and pretty soon I had a decent introduction written up. It even sparked some debate between developers about unresolved design questions. Funny how a contribution like that is easier to make when you’re new to the project. Much the same happened with fcgi, a nice “persistent CGI handler” similar to FastCGI but much simpler.
Matthew: Tell us something really cool about Launchpad that not enough people know about.
Jeroen: My personal favourite is a very basic one that we’ve had for ages: because Launchpad mirrors subversion and CVS repositories, you can play with the code of some project and still have full revision control.
When I wanted to mess around with a piece of code I got from the internet, I used to download a tarball, unpack, work on the code, then diff against a freshly-unpacked copy. Or I’d check out the repository and never commit. But now I can just branch off Launchpad’s copy of the source tree, and commit changes locally to my own branch.
Matthew: What’s your favourite TLA?
Jeroen: Hard one, since I have over 23,000 to choose from! I keep them here.
It started out as a joke about TLA-space pollution, but some people actually use it as a reference. I do, too.
What’s my favourite TLA? I like the name of the list itself, which is a meta-TLA. GTF stands for GPL’ed TLA FAQ. If you send me a new entry you become part of the GTF Contributor Program or GCP, and you get a little logo you can show on your home page.
Matthew: Okay, Kiko‘s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?
Jeroen:Probably checking for a 10-Baht coin so I can get a motorcycle ride back to the main road. The dogs get a little frisky sometimes, so the wild ride may be marginally safer. The coin looks just like a worn 2-euro coin at about 1/10th the price. They’re similar enough that many coin slot machines had to be recalibrated.
Matthew: Thanks Jeroen!
Launchpad 2.2.2: easier upstream bug linking
Published by Matthew Revell February 26, 2009 in Releases
The Launchpad team is proud to announce the release of Launchpad 2.2.2! Let’s look at what’s new this month.
Now easier to add upstream links to bug reports
If you’re using Launchpad to track a bug that you think may also be reported elsewhere — such as in a project’s Bugzilla — it’s now easier to find that bug report.
Launchpad developer Graham Binns explains:
Launchpad will now give you direct links to the bug search and filing forms in a project’s external tracker, so long as Launchpad knows the tracker’s location.
To find the links, all you have to do is click “Also affects project” on the bug report and select the project you want to link to.
There’s more in Graham’s blog post.
Also in Launchpad 2.2.2
February saw the Launchpad team dedicate a week to tackling slower-loading pages. Read our write-up of what happened in Launchpad Performance Week.
You can find full details of Launchpad 2.2.2 on its milestone page.
If you come across a bug, please report it!
See you next month!
We’ll be releasing Launchpad 2.2.3 at the start of April. In the mean time, stay up to date with Launchpad news and views right here on our blog.
And as always, you can join us in #launchpad on Freenode and on the launchpad-users mailing list.
Links to external bug trackers right where you need them
Published by Graham Binns in Bug Tracking, Cool new stuff
Linking Launchpad bugs to upstream bugs can be hard work. You don’t necessarily know whether the bug is reported on the upstream tracker, and if you don’t know where the upstream project tracks its bugs you have to go and find out before you can file the bug and link the Launchpad bug to it.
We understand that this process can be a bit of a pain, so we’re introducing a feature that should make linking to upstream bugs a bit easier: Launchpad will now give you direct links to the bug search and filing forms in a project’s external tracker, so long as Launchpad knows the location of the project’s tracker and, if the tracker tracks more than one project, which project on the external tracker the Launchpad project refers to (so, for example, Launchpad needs to know that the Launchpad project ‘evolution’ links to the ‘Evolution’ product in the Gnome Bugzilla).
And because we know that a project maintainer shouldn’t have to go back to Launchpad and add the link to the remote project when Launchpad should be able to work it out for itself we’ve fixed that problem, too: Launchpad will check all the projects that are linked to a remote bug tracker and will try to deduce which remote project they’re linked to by looking at the bug watches that are registered against that bug tracker. Of course, this isn’t an exact science, and we’ll have to correct some of these auto-generated links manually, but hopefully it won’t take more than a few days for us to straighten out the kinks.
In order to get to remote bug tracker links, all you have to do is click Also affects project on the bug report and select the project that you want to link to. Launchpad will then offer you the links.
We’re going to be working to improve this further in the coming Launchpad development cycle, so keep your eyes on this blog for further information.
Roundup of the first Launchpad Performance Week
Published by Matthew Revell in Launchpad Performance Week
Back at the beginning of February, we ran our first Launchpad Performance Week.
Our aim was to find pages that, although they weren’t slow enough to trigger our internal warning, were nonetheless taking too long load. The first thing we did was to get our internal warning system to generate a report when a page takes 25 seconds to load, rather than 30 seconds.
So, armed with a list of sloth-like pages, each part of the Launchpad team went away with one aim: to fix whatever was preventing those pages from loading in a reasonable time.
Those fixed pages have been around on Launchpad’s edge environment for some time now and hit production with our 2.2.2 release.
So, let’s see what the team have been working on.
Faster bug pages
As a bug in Launchpad gets more attention — whether you measure that by the number of comments or subscribers — it takes more work to display it. That has led to particularly popular bugs, including the oft-linked-to bug #1, taking too long to load.
Two of the big pain points, on bug pages, were comments and the box listing the bug’s subscribers. For most bugs, they present no problem. However, bugs with many comments/subscribers were nudging Launchpad’s hard timeout limit.
Gavin tackled the slow loading of multiple comments by changing the bug page to display only 80 comments. Where the 81st comment would be there’s now a link to view the rest of the comments or post a new comment.
Tom‘s approach to the subscriber list was to load it asynchronously, preventing it from acting as a bottle-neck to loading the rest of the page. So far, there’s very little wait between the rest of the page loading and the subscriber list appearing.
Personal Package Archive overview pages
The Soyuz team worked on PPA overview pages. Take a look at the Exaile development team’s PPA as an example.
Two hold-ups were caused on this page, particularly for PPAs with many packages: the disk usage information and the detail for each package. Both are now loaded asynchronously, the package detail only being loaded when you click its header.
There’s more detail from Julian in his blog post.
Translation pages
The translations pages are some of the most data-intesnive in all of Launchpad. Danilo talks about the tranlsations team’s Launchpad Performance Week work in his blog post.
Code project cloud
Launchpad Code developer, Jonathan, wrote on his own blog about his work on the project cloud page:
The Launchpad Code home page is now a little bit nicer and a little bit faster.
For a while now, the page has had a tag cloud showing some projects that host branches on Launchpad. The tag cloud is drawn based on these two rules:
- the more branches, the bigger the tag
- the more recent the last commit, the less faded the tag.
Up until recently, the home page only showed some projects starting with ‘A’ — which is a bit silly. My recent patch changed the query to show the most branch-y projects on Launchpad. It looks a lot nicer, IMO.
We also got rid of the green / blue distinction. No one knew what it meant and it made the page more visually muddled. There are still some tweaks we can make, but I think this is definitely an improvement.
And elsewhere
We made a number of smaller changes right across Launchpad, as part of the Performance Week. We’re also working on introducing much more AJAX into Launchpad’s web interface, which should make the experience of using Launchpad feel much quicker.
We’ll be holding another Launchpad Performance Week in April, this time cutting our definition of slow page by a further five seconds. Again, we’ll be posting details of what we did right here.
New privacy features for commercial subscribers
Published by Matthew Revell February 25, 2009 in General
Launchpad is set up to make it easy for groups to come together spontaneously around tasks big or small. Take this bug as an example: it affects three projects that share the same code. Launchpad brings them together to find a fix.
But there are times when collaboration needs to be done privately. It could be because of security concerns, or confidentiality obligations to a client, or to coordinate the timing of events for marketing purposes, etc.
Launchpad already enables individual bugs to be marked as private but, until now, that’s been all. However, we’re running an interesting beta program at the moment that allows projects to default to both private bugs and private branches. As this will be of most interest to projects who aren’t ready to share their code, we’ll offer it by commercial subscription.
We’ve already been offering basic commercial subscriptions for a few months now. While Launchpad is always free of charge for free software projects, it also hosts some projects with non-free licenses, and charges them a fee to offset the costs of running the site. Until now, these commercial subscriptions have just meant access to Launchpad with no extra features. But following our beta of private branches and private bugs, we hope to offer a wider range of features to commercial subscribers, as they are likely to have different privacy needs from free software projects. If you’re a commercial subscriber and want to take part in the beta, or if you’re considering a commercial subscription, please contact us.
Of course, commercial subscriptions don’t take anything away from the free software projects that use Launchpad. They remain the focus of our development work, particularly as we move to open sourcing Launchpad itself.
Meet Tim Penhey
Published by Matthew Revell in Meet the devs
We’re back in New Zealand for today’s Launchpad developer interview with Tim Penhey.
Matthew: What do you do on the Launchpad team?
Tim: I lead the team that works on the Bazaar code-hosting side of Launchpad. This includes all the pages that are under the “Code” tab, the linking of branches to other parts of the Launchpad system, the services and scripts behind the scenes that allow the hosting of branches, and the branch browser (Loggerhead).
Matthew: Can we see something in Launchpad that you’ve worked on?
Tim: I’ve touched probably every page visible under the “Code” tab. A large amount of work is going into the work flows around code reviews, and that is where I’ve been spending a lot of time recently.
Matthew: Where do you work?
Tim: I work from home, and home for me is currently Dunedin, New Zealand. I turned one of the bedrooms in the house into an office, which contains my desk, a nice comfortable leather chair, and too much computer equipment.
Matthew: What can you see from your office window?
Tim: Our deck, and beyond that our back yard which is mostly grass with a trampoline for the girls and part of the garden which currently has several pumpkin plants doing extremely well.
Matthew: What did you do before working at Canonical?
Tim: I worked as a contract developer in London, UK. I primarily worked at investment banks working on their back office risk systems. I had worked for Lehman Brothers (RIP), Royal Bank of Scotland, Barclays Capital, and Cantor Fitzgerald. Prior to that I had a stint at Reuters working on their stock exchange connectivity software.
Matthew: How did you get into free software?
Tim: Sometimes I wonder if I am “into” free software. As far as using free software, I’ve had an aversion to paying for Microsoft software when perfectly good free alternatives were around for a while. I toyed with Linux a couple of times back with Red Had 7.1, and some SUSE version shortly after that, but I didn’t make the switch until I came across the Hoary Hedgehog release candidate. I’ve been using Ubuntu since then.
I’ve been meaning to get into actually contributing to free software for so long. Every time I looked into it I got put off by the massive leaps into a group’s culture and code base. I use KDE and have it as my main desktop almost exclusively, and I’d love to contribute to KDE, but it seems that there are always the “KDE” or “QT” ways of doing things. I had a background in C++, but they don’t use what I’d consider “pure” C++, so there is always a huge learning curve, and I don’t have the time right now to invest in that. I have a three girls, 8, 6, and 3 and a half (don’t forget the half), and they take up a lot of my non-work time. I’ve had the opportunity to contribute a few small patches to Bazaar, and I’d still like to contribute to other projects.
Matthew: What’s more important? Principle or pragmatism?
Tim: That’s like saying: What is more important? Food or water? They are both important. Particularly when developing code if you don’t have one tempered
with the other you end up unreadable spaghetti or gold plated code. I lean towards more principle as it tends to give cleaner code, but sometimes pragmatism wins out to actually get code out and useful. Code that isn’t used might as well not be written.
Matthew: Do you/have you contribute(d) to any free software projects?
Tim: I’ve got a couple of small patches into Bazaar. I use aliases a lot with bash, and also with Bazaar, but didn’t like that I had to edit the configuration file to add aliases, so scratching my own itch, I added the ‘alias’ command to Bazaar. I’ve also done some work on the PQM project, but most of my work is on Launchpad.
Matthew: Tell us something really cool about Launchpad that not enough people know about.
Tim: Code reviews. We are actively working to make them better, but the coolest thing about code reviews in Launchpad, is that you can do them entirely through email. Not only can you go to the web page and add a comment, and that comment gets emailed out to all interested parties, but you can reply to the emails using your mail client, and those replies are parsed, added to the review, and emailed out to the interested parties just as if you had entered them through the web interface.
A lot of work has also gone in recently to expose the code review functionality through launchpadlib as well. This will allow people to integrate Launchpad’s review functionality into other tools.
Matthew: Is the film Eagle v Shark an accurate picture of life in New Zealand?
Tim: To be honest, I have no idea as I haven’t seen the film. It has been on my list of something to get on DVD at some stage, but I don’t have it yet.
Matthew: Okay, Kiko‘s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?
Tim: Getting my credit card to pay for books from Amazon. Books are very expensive in NZ. On my coffee scale, it is almost twice as expensive as the UK. Three coffees in the UK for a paperback, whereas it is closer to five or six coffees in NZ.
Matthew: Thanks Tim!
Launchpad offline 00.00 – 01.00 UTC 26th February
Published by Matthew Revell February 24, 2009 in Notifications
Launchpad will be offline for one hour from 00.00 UTC on Thursday the 26th February while we roll-out the code for our latest release, Launchpad 2.2.2.
Going offline: 00.00 UTC 26th February 2009
Expected back: 01.00 UTC 26th February 2009
We’ll post details of the release to this blog!
