Canonical Voices

Posts tagged with 'code'

Curtis Hovey

Launchpad is ending support for multi-tenancy for branches and bugs to ensure that projects can manage the disclosure of private information. This is a fundamental change to how launchpad permits communities to share projects. Very few users will be affected by this change, but several communities will need to change how they work with private bugs and branches.

Launchpad currently permits users to create private bugs or branches that cannot be seen by the project maintainers, or the project’s other communities. This feature permits communities and companies to develop features in secret until they are ready to share their work with the other communities. This exclusivity feature is difficult to use, difficult to maintain, and makes Launchpad slow. This feature also contradicts the project maintainer’s need to be informed and to manage the disclosure of confidential information. When multiple parties can control privacy on a project, important information is lost.

While discussing the proposed changes with Launchpad stakeholders, I was surprised that most believed that the project maintainers could see the private bugs they were reporting — they wanted to collaborate, but the subscription-as-access mechanism is faulty. There are thousands of private bugs reported in Launchpad that cannot be fixed because the person who can fix the issue is not subscribed.

A contributing reason to drop support for private branches on project you do not maintain is that the feature is fundamentally broken. Privacy is inherited from the base branch. If you cannot access the base branch your branch is stacked on, you are locked out. Project owners can, and accidentally do, lock out contributors. You cannot subscribe someone to review the security concerns in your branch if that user does not have access to the base branch. Project contributors must subscribe each other to their respective branches to collaborate on a fix or feature.

This change is a part of a super-feature called Disclosure. To ensure that confidential data is not accidentally disclosed, project maintainers will be able to view and change who has access to confidential project information. Maintainers can add users to security or proprietary policies to grant access to all the information in the respective policy. You will not need to subscribe users to individual bugs or branches, unless you want to grant an exception to a user to access one confidential piece of information.

Read more
mitechie

Just a heads up, this week’s CoffeeHouseCoders (CHC) Detroit-ish will be a bit different. One of the goals of moving the location to the new Caribou was that we get access to the meeting room. This opens up the opportunity for us to have some group discussion and such around various topics. We’re going to give that a shot this week with a group viewing of YUI Theater video viewings and JavaScript discussion.

Most of us do at least some JavaScript in our work and projects so I think it’s relevant and should be fun to geek out before the holidays start up. I’ll have a little projector and speaker and with the new videos from YUIConf 2011 going up, it’ll be nice to set aside some time to catch up on some of the recorded presentations. Take a peek and set aside one or two "must watch" videos for Wed night! Not all of the videos are YUI specific, so it should be useful for all of us doing JavaScript.


Read more
Raphaël Badin

Edit 2011-11-15 08:18 UTC: The problem is now fixed and we’ve re-enabled the new menu.

Edit 2011-11-11 13:42 UTC: We’ve temporarily disabled the new menu while we fix some unfortunate side effect.

We’ve just deployed a new, simplified version of the branch menu displayed on the right hand side of personal code pages (e.g. personal page for the Launchpad team). It looks like this:

Old menu

New menu

Calculating the number of branches took way too much time for people/teams with a huge number of branches (e.g. https://code.launchpad.net/~ubuntu-branches), up to the point that they were getting timeouts.

The new design, along with optimisations we’ve made to the database queries, should improve performance for everyone.

Read more
Martin Pool

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.

Read more
Aaron Bentley

I recently posted about Initializing page JavaScript from the JSONCache. Now I’m pleased to announce that you can also get updated copies of the IJSONRequestCache, to make it easier to update your page.

Brad Crittenden and I started work on this at the Dublin Thunderdome, and it’s finally been deployed. What this means is that for basically any page on Launchpad, you can append /++model++ to the URL, to get a fresh copy of the IJSONRequestCache. With ++model++, a change will typically require only two roundtrips; one to make a change, and one to retrieve an updated model. Future work may reduce this to a single roundtrip.

Why ++model++, not ++cache++? Cache is a really poor name for what the IJSONRequestCache is. Rather than providing fast access to whatever data has been previously retrieved, it is a complete collection of all the relevant data.

In Launchpad, the IJSonRequestCache is associated with the view, so we’re trying to rebrand it as the “view model”. This may seem strange from an MVC (Model, View Controller) perspective, but MVC can be recursive. A view may use a model to render itself.

Read more
Matthew Revell

Source package recipes

A pint of ale

Here’s a quick pub quiz:

Question: How do you make packages for Ubuntu?

You can choose from the following answers:

  1. learn Debian packaging through hours of study and practice
  2. borrow existing packaging from elsewhere, throw a couple of Bazaar branches together and let Launchpad handle the rest
  3. Uruguay in both 1930 and 1950.

If you selected either of the first answers you’d be right.

Okay, so, if you want to do it for real — i.e. become an Ubuntu MOTU or otherwise create Debian-style packages from scratch — then you still need to go through the hard work.

However, for everyone else who really just needs to get something out there and working for, say, a group of beta testers, we now have Launchpad’s source package recipes.

How it works, in three steps

It’s almost ridiculously easy to set up a source package build:

  1. Choose a branch in Launchpad, whether hosted directly or imported.
  2. Write a short recipe that tells Launchpad which other branches to pull in, for example to provide packaging or make the code buildable.
  3. Paste your recipe into Launchpad.

And that’s it. Within a few minutes you can set up a daily build direct from your trunk or any other buildable branch in Launchpad.

Watch how it works in our screencast:

An example

Alvin Hall

Let’s say you’re the developer of a home finance application called Alvin. You track your project’s code using Git and host it on your own server. For the past couple of years Alvin has been packaged in the Ubuntu universe and your trunk has also been imported from Git to a Bazaar branch in Launchpad at lp:alvin.

Just as you’re approaching Alvin’s next release, you want to get some wider testing. In the past, you’ve published a nightly tarball and provided instructions on manual installation. That’s given you a handful of dedicated beta testers but you’re worried that you’re asking too much of people.

With Launchpad’s source package recipes, you write a short recipe that pulls in your trunk branch, adds the packaging from Alvin’s existing Ubuntu package and then builds an installable Ubuntu package in the PPA of your choice:


# bzr-builder format 0.3 deb-version 2.0beta+{revno}
lp:alvin
nest-part packaging lp:ubuntu/alvin debian debian

Paste the recipe into Launchpad and with a couple of clicks you have a daily build of your trunk, that’s published as an Ubuntu package in your PPA.

Now you can ask people to test the latest Alvin code by doing no more than adding your PPA to their system. Launchpad will build a new version of the package on each day it spots a change in your trunk (or the Ubuntu packaging). For your beta testers, any changes will show up just like any other Ubuntu update.

Simple as that!

Here’s a quick recap of how it works: you can take any buildable branch — whether hosted in directly Launchpad or imported from Git, Subversion, CVS or Bazaar hosted elsewhere — merge or nest other branches, add packaging and then leave it to Launchpad to create a daily build that it publishes in your chosen PPA.

Seeing it in action

List of daily builds in Launchpad

During the beta, people added a whole range of source package recipes, with a list of more than 350 daily builds as I write this.

Daily builds on Launchpad right now include Project Neon, who have around sixty recipes providing daily builds of KDE and Amarok. There are also daily builds of the Scribus DTP app, Audacity and the scriptable screen reader Gnome Orca.

Try it out

It’s easy to get your own source package recipes and daily builds up and running.

Start at our Getting Started guide and screencast.

I’ll leave the last word to Luke Benstead, who has been using source package recipes while developing a set of game libraries:

I’ve been using LP to develop some small open source game libraries. Because there are quite a few of them, packaging them all is a pain, so the package builds have worked out pretty well for them.

Now I get nightly builds delivered to a PPA, so I know that if I fix a bug it’s reflected to all my machines. And my recipes are only a single line so they’ve been really easy to use. I’m not really sure how they could be easier.

Images:
Beer photo by dearbarbie. CC-BY-SA.
Alvin Hall photo by Phil Guest. CC-BY-SA.

Read more
Julian Edwards

Continuing with the recent improvements to the build farm – Jelmer has made another massive one.

The last major scalability problem that we had was one where the whole farm was blocked when a single builder was ready to upload a build. In the case of large packages, like the kernel, the manager process could block for over a minute while it waited for the upload processor to unpack the package and verify its contents.

Jelmer’s work has decoupled the upload processing from the build farm manager process. What happens now is that the files collected from the builder are thrown into a staging queue area and then the manager process immediately continues with polling the rest of the builders, unblocked. A cron job will then process the builder upload queue at 1 minute intervals.

You can see the dramatic effect this has had on the overall queue for the PPA builders here:
Build Farm Queue Size

This is quite an incredible improvement as you can see! But we’re not stopping there, we’re currently doing a massive refactoring of the builder dispatching code so it’s all fully asynchronous. When this is all done we’re going to be in superb shape to support an increase in load that’s anticipated from the increasing number of people using the package recipes.

Read more
Matthew Revell

As I’ve said before, Launchpad is pretty big. Getting to know everything you can to do in Launchpad can take a while.

Of course, there are the user guide, the tour and the dev wiki even has a feature check-list. It’s still easy to miss things.

So, I’m turning the fifth day of each week into Feature Friday :)

I’m gonna kick off with something I use a lot and that, to be honest, is more a Bazaar feature, than a Launchpad feature:

bzr commit -m "Adds email functionality to the client, thereby obeying Zawinski's law." --fixes lp:1234

Adding --fixes lp:1234 to a commit tells Bazaar that the branch contains a fix for bug 1234 tracked in Launchpad.

The next time you push the branch to Launchpad, Launchpad will create a link between the branch and bug 1234.

Read more
Matthew Revell

Tim has made a couple of improvements to the way that comments are displayed on merge proposals.

The first is pretty simple but makes it far easier to see which merge proposals need attention. Up until now, if you gave your merge proposal a description it would show up as a comment. This made it harder to see which merge proposals had zero activity.

Now, your description no longer shows up as a comment. And you can edit your description in-line using the same Javascript editor as you’ll find on bug pages.

The other change affects merge proposals that supersede another merge proposal. The merge proposal page explicitly states that it supersedes a previous proposal.

Notice showing the merge proposal supersedes another

It also lists all the comments from that previous review, giving them a yellow background and a link to the superseded review so you can easily tell them apart from comments on the current review.

A comment from the superseded merge proposal

Read more