New approaches to new bug listings
Published by Aaron Bentley December 15, 2011 in General
The new bug listings listings were the first time my squad, the Orange Squad, had a chance to work on some really nice in-depth client-side UI since our squad was formed. Not only were we implementing the feature, we wanted to lay groundwork for future features. Here are some of the new things we’ve done.
Synchronized client-side and server-side rendering
Early on, we decided to try out the Mustache template language, because it has client and server implementations. Although we wanted to make a really responsive client-side UI, we also wanted to have server-side rendering, so that we’re not broken for web crawlers and those with JavaScript disabled. Being able to use the same template on the server and the client seemed ideal, since it would ensure identical rendering, regardless what environment the rendering was done in.
It’s been a mixed bag. We did accomplish the goal of using a single template across client and server, but there are significant bugs on both sides.
The JavaScript implementation, mustache.js, is slow on Firefox. Rendering 75 rows of data takes a noticeable length of time. If you’re a member of our beta team, you can see what I mean. Go to the bugs page for Launchpad itself in Firefox. Click Next. Now click Previous. This will load the data from cache, but it still takes a visible length of time before the listings are updated (and the Previous link goes grey).
mustache.js also has bugs that cause it to eat newlines and whitespace, but those can be worked around by using the appropriate entity references, e.g. replacing “\n” with “ ”
The Python implementation, Pystache, does not implement scoping correctly. It is supposed to be possible to access outer variables from within a loop. On the client, we use this to control the visibility of fields while looping over rows. On the server, we have to inject these control variables into every row in order for them to be in scope.
We needed a way to load new batches of data. Mustache can use JSON data as its input. Launchpad’s web pages have long had the ability to provide JSON data to JavaScript, but Brad Crittenden and I recently added support for retrieving the same data without the page, via a special ++model++ URL. This seemed like the perfect fit to me, and it’s turned out pretty well. Using the ++model++ URL rather than a the Launchpad web service means the server-side rendering can tightly parallel the client-side rendering. Each uses the same data to render the same template. It also means we don’t have to develop a new API, which would probably be too page-specific.
Client-side Feature Flags
While in development, the feature was hidden behind a Feature Flag. But at one point, we found we wanted access to feature flags on the client side, so we’ve now implemented that.
History as Model
We wanted users to be able to use their browser’s Next and Back buttons in a sensible way, especially if they wanted to return to previous settings. We also wanted all our widgets to have a consistent understanding of the page state.
We were able to address both of these desires by using YUI’s History object as a common model object for all widgets. History provides a key/value mapping, so it can be used as a model. That mapping gets updated when the user clicks their browser next and back buttons. And when we update History programmatically, we can update the URL to reflect the page state, so that the user can bookmark the page (or reload it) and get the same results. Any update to History, whether from the user or from code, causes an event to be fired.
We’re able to boil the page state down to a batch identifier and a list of which fields are currently visible. The actual batches are stored elsewhere, because History isn’t a great place to store large amounts of data. For one thing, there are limits on the amount of data that can be stored. For another, the implementation that works with old browsers, HistoryHash, can’t store anything more complex than a string as a value.
All our widgets then listen for events indicating History has changed, and update themselves according to the new values in the model.
Summing up
It’s been an interesting feature to work on, both because of the new techniques we’ve been able to try out, and because we’ve been closely involved with the Product team, trying to bring their designs to life. We haven’t quite finalized it yet, but I’m going on leave today, so I wanted to let you know what we’ve all been up to. Happy holidays!
Legacy, performance, testing: 6 months of new critical bugs analyzed
Published by Francis J. Lacoste December 9, 2011 in General
The Launchpad maintenance teams have been working since the beginning of the year at reducing our Critical bugs count to 0. Without much success this far. The long term trend keeps the backlog at around 300. And it’s not because we haven’t been fixing these. Since the beginning of the year, more than 800 Critical bugs were fixed, but more than 900 were reported 
So I investigated what was the source of all these new critical bugs we were finding. A random sample of 50 critical bugs filed were analyzed to see where and why they were introduced. The full analysis is available as a published Google document.
Here are the most interesting findings from the report:
- Most of the new bugs (68%) are actually legacy issues lurking in our code base.
- Performance and spotty test coverage represents together more than 50% of the cause of our new bugs. We should refocus maintenance on tackling performance problems, that’s what is going to bring us the most bang for the bucks (even though it’s not cheap).
- As a team, we should increase our awareness of testing techniques and testing coverage. Always do TDD, maybe investigate ATDD to increase the coverage and documentation our the business rules we should be supporting.
- We also need to pay more attention to how code is deployed, it’s now very usual for scripts to be interrupted, and for the new and ancient version of the code to operate in parallel.
Another way of looking at this is that Launchpad represents a very deep mine of technical debt. We don’t know how exactly deep the mine is, but we are going to find existing Critical issues until we hit the bottom of the mine. (Or until we finish refactoring enough of Launchpad for better testing and performance. That’s what the SOA project is all about.)
In the mean time, we should pay attention to regressions and fallouts, (those are really the new criticals) to make sure that we aren’t extending the mine!
Photo by Brian W. Tobin. Licence: CC BY-NC-ND 2.0.
Custom bug listings – have your say
Published by Dan Harrop-Griffiths December 6, 2011 in General
Our custom bug listings beta has been up and running for just over a week now – thanks to everyone in the Launchpad beta testers group that have tried it out, and thank you for all your valuable feedback and comments. If you haven’t tried it yet, you can get access by joining our beta team here: https://launchpad.net/~launchpad-beta-testers
We want to improve how the default information is displayed to make this tool work better, so we’ve put together a super-quick survey to find out:
- What information about a bug you most want to see in bug listings
- What the default ‘order by’ options should be
- If you’d like to see any other ‘order by’ options.
These three questions should only take a few minutes to complete, but they’ll add real value to our work redesigning how bug listings appear and function. Here’s the link if you’d like to take part
Launchpad translations disruption 10.00 UTC 2011-11-29
Published by Matthew Revell November 28, 2011 in Notifications, Translations
Launchpad translations will be unavailable for around one hour, starting 10.00 UTC, on Tuesday 2011-11-29, to allow us to open the translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS).
We tried this last week but hit some problems. Rather than prolong the disruption, we decided to bring translations back online and delay the opening of Precise’s translations until after we’d fixed the issue.
While we’re opening Precise’s translations, Launchpad will not be importing translation files and the web interface for making and reviewing translations will be unavailable. This includes imports for translation uploads, but also imports from Bazaar branches.
Once this is done, imports will resume normally and any backlog should be processed quickly after that.
Customisable bug listings in beta!
Published by Dan Harrop-Griffiths November 24, 2011 in Bug Tracking
The information displayed with bug listings is often not what you want to see – you might not be interested in bug heat and want to see bug age, but it’s not there. Looking at this problem, we’ve come up with a new beta feature: custom bug listings. A lot of you have said that you’d like to be able to filter bugs in a way that works best for you. Hopefully this new functionality should help with this goal:
- You’ll be able to sort bugs by criteria such as name, importance and status.
- You can put them into ascending or descending order without having to reload the page.
- You’ll be able to save your preferred layout.
We’ve also redesigned how bug listings are displayed – fitting more information into each bug listing, and adding sort options such as bug age, assignee, reporter, and tags.
We’ve done some successful rounds of user testing and would love to hear your options on this great new feature. We’ve just released it into beta. To see it, you need to be part of Launchpad Beta Testers. To try it out, take a look at any bugs listing, like this one for Openstack.
Let us know how you get on with it: either report a bug (using the bug tag bug-columns) or join us on launchpad-users.
2011/11/28 update: we have temporarily suspended the beta, but we’ll have it back in the next day or so
Photo by Stephen Fulljames. Licence: CC-BY-SA.
Ending support for multi-tenancy
Published by Curtis Hovey November 23, 2011 in Bug Tracking, Code, Coming changes
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.
Launchpad translations service disruption update
Published by Dan Harrop-Griffiths November 22, 2011 in Notifications
Launchpad translations was due to be unavailable from 10.00 UTC for around one hour this morning to allow us to set up translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS).
However, by about 10.15 UTC we encountered problems with data already in Precise’s translations. We weren’t sure how long it’d take to fix this issue, so decided it was better to reschedule the translations downtime for another day.
Sorry for the brief interruption to service. We’ll give you at least 24 hours notice before attempting this work again.
Launchpad translations disruption 10.00 UTC 2011-11-22
Published by Matthew Revell November 21, 2011 in Notifications, Translations
Launchpad translations will be unavailable for around one hour, starting 10.00 UTC, on Tuesday 2011-11-22.
During this time Launchpad will not be importing translation files and the web interface for making and reviewing translations will be unavailable. This includes imports for translation uploads, but also imports from Bazaar branches.
We are suspending the service temporarily to allow us to set up translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS). Once this is done, imports will resume normally and any backlog should be processed quickly after that.
Ubuntu SSO and Launchpad service disruption 10.30 UTC 17th November 2011
Published by Matthew Revell November 14, 2011 in Notifications
Ubuntu’s single sign-on service will be read-only for around 15 minutes starting at 10.30 UTC on the 17th November. At the same time, Launchpad will be offline.
This means that you should be able to log into websites that depend on the Ubuntu single sign-on service, but not make changes to your login or register a new account. It also means that anything involving Launchpad will be unavailable during that time.
Starts: 10.30 UTC 17th November 2011
Expected back by: 10.45 UTC 17th November 2011
We’re sorry for this service disruption. During this time we’ll be making a database upgrade.
Improved performance for personal code pages
Published by Raphaël Badin November 10, 2011 in Code, General, Performance
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.
