2

How do we determine “What’s next?”

Published by Francis J. Lacoste April 29, 2011 in General

What's next?

To many people, Launchpad development looks like a black box. People asks for thing in various places (the bug tracker, the mailing lists, IRC, directly to developers, or simply wish it out loud) and then, often unexpectedly, Lauchpad will change.

We strive to work in the open, discussing changes on the development mailing list or on the bug tracker, publishing our Kanban board,  announcing stuff here on this blog, often trying to contact concerned users directly. But because Launchpad is a big project catering to the needs of many different type of users, it’s easy to miss out on some people.

So here it is, the Definitive guide on how Launchpad folks decides what to work on next!

Since the squad reorganisation, the principles used to determine what’s next will depend on whether we are looking at a maintenance squad or a feature squad.

What’s next for maintenance?

Let’s start by the easiest case: maintenance. Squads on maintenance works from the bugs in the bug tracker. And then we work on bugs starting from highest importance (Critical currently). Our triage rules explains how we determine bug importance. That’s a very verbose page that in practice means today, treat it as critical if:

All the other distinctions  between High, Medium and Low at this point are  moot until we clear the backlog of such issues (see my status post to see how we are doing there). That’s not to say that we don’t fix High, Medium or Low bugs. Developers can, at their discretion, decide to work on such bugs if they happen to work in the area, or they find it related to a critical bug, or just because. But developers on maintenance will be generally found fixing critical bugs at this time.

Which one? We usually try to work on the “hot” ones. Those are the ones happening frequently or recently. But after that, it’s really up to developer’s discretion. They’ll usually pick based on their area of competence or area in which they want to acquire competence.

Once we are done with the Critical backlog, then we’ll tackle High bugs.  Again, the same kind of decision process will be used to decide which one to pick next: that is, developer’s discretion. The idea is that time on maintenance rotation should be mostly self-directed for developers.

There is another way that a bug can jump the queue, it can be escalated to Critical importance. Since it’s closely related to the stakeholders’ process, I will cover it in my next post where I’ll discuss on how we determine What’s Next? for  feature squads.

Photo by Crystal. Licence: CC BY 2.0.

0

Launchpad read-only 08.00 UTC 4th May

Published by Francis J. Lacoste in Notifications

Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 08.00 UTC on the 4th May 2011.

Starts: 08.00 UTC 4th May 2011
Expected to end by: 09.30 UTC 4th May 2011

This is to allow for a structural update to Launchpad’s database.

6

Ubuntu 11.04

Published by Matthew Revell April 28, 2011 in General

Bloke dressed as a narwhalCongratulations to everyone in the Ubuntu community on the successful release of Ubuntu 11.04!

Here’s to the next six months of oneiric fun.

Photo by Sharon Terry. Licence: CC-BY-ND 2.0.

0

Gufw in Launchpad

Published by Matthew Revell April 26, 2011 in Projects

GUFW's logoIf you’re an Ubuntu user, it’s likely that you’ve used UFW — the Uncomplicated Firewall — and maybe also its graphical front-end, Gufw.

I spoke to Marcos Costales from Gufw to ask about the project and their use of Launchpad.

Matthew: What prompted you to start the project?

Marcos: In 2008 I was translating and testing, but I wanted to contribute more. When Canonical released ufw, I read some reviews that a firewall using the shell was not an uncomplicated firewall; reviews did not see that ufw was perfect for servers and a base with great ideas for something else, I saw a clear opportunity for the development of an application like Gufw.

Matthew: How many of you are working on it?

Marcos: After the first week following release, Vadim joined the project and we were able to generate a lot of expectation. It was amazing to see how Gufw grew exponentially thanks to the contribution of the community. An important point was Cedrick’s mockup for setting a good interface.

From here I would like to thank Vadim, Emilio, Raúl, Planella, Rubén, Rogério, Cedrick and Devid, Gufw is what it is thanks to them.

We are currently working on an application that really simplifies the task of setting up a firewall: very minimalistic, easy to use and understand.

Matthew: How much connection is there between the Gufw and UFW communities?

Marcos: From Gufw we pay attention to the next ufw versions and we request changes we need. We want to thank Jamie for his effort and interest in all of our requests.

There is also an awesome work of documentation taking place in the Ubuntu Wiki.

Matthew: Does Launchpad help the two projects work together?

Marcos CostalesMarcos: Yes, we can follow the blueprints of the next ufw version and review which changes could affect Gufw. We can easily reassign ufw and gufw bugs…

Matthew: Why did you choose Launchpad?

Marcos: Gufw started in Google Code. After one month we moved to Launchpad, and it certainly was one of our best decisions because it offers us all necessary services and an amazing integration between them.

Matthew: What’s your favourite Launchpad feature?

Marcos: Translations. I am a translator in external projects to Launchpad, and I must say that the usability and simplicity of Launchpad is unique.

Matthew: What would you most like to see added to Launchpad?

Marcos: Maybe a small space for a custom website. We must use an external hosting for the main project website.

Matthew: What do you think is Launchpad’s biggest weakness?

Marcos: At first Launchpad seems overly complex and big (compared for example with Google Code). One idea would be to have two views according to the needs/experience of the project: the current one and an easier to use one.

Matthew: Are you looking for people to contribute?

Marcos: Of course we are. There are always pending tasks for anyone who wants to help and everyone is welcome.

Matthew: Thanks Marcos!

1

See the number of duplicates

Published by Matthew Revell April 25, 2011 in Bug Tracking

Duplicate bug countBrian Murray has written a GreaseMonkey script to show how many duplicates a bug has.

He writes:

I was looking at a bug with a large number of duplicates the other day and found my self wondering exactly how many duplicates it had. This information actually appears in the page source for the bug report however its a bit hard to read there!

I’ve hightlighted the duplicate count in the screenshot to really point out where it is.

I’ve also updated the firefox-lp-improvements PPA which contains a Firefox extension collecting all of the Launchpad Greasemonkey scripts with the new script.

0

Ajax comes to Blueprint

Published by Matthew Revell April 24, 2011 in General

An architectural blueprintRejoice Blueprint users for Tim has brought the glory of Ajax to the main blueprint page.

He writes:

Now we can update the following without reloading the primary page:

  • title – the H1 heading
  • summary
  • whiteboard
  • assignee
  • drafter
  • approver
  • priority
  • implementation status
  • definition status

Using the new custom events that the page raises when the context object changes (using YUI magic and API PATCH requests), when you change the title of the blueprint, the document title (title bar) and the breadcrumbs also change. When the implementation status is updated, the overall status updates, and the “started by” and “completed by” are shown or hidden as appropriate.

This is work that I’ve wanted to see done for almost a year, and recent other changes I’ve done adding more widget wrappers and javascript goodness have made this possible without adding copious amounts of custom javascript.

A side-effect of these changes is that there are now more fields exported over the API for blueprints.

Photo by Will Scullin. Licence: CC BY 2.0

0

Updated featured projects list

Published by Matthew Revell April 23, 2011 in General

Last week I asked for suggestions of what should be on the Launchpad front-page featured project list.

Thanks for your suggestions! Based on your comments, I’ve added the following projects to the front page:

I’m also going to look at better ways of show-casing the projects of Launchpad. I’ll blog with more info soon.

1

5, 9, 23, 51, and other numbers

Published by Francis J. Lacoste April 22, 2011 in General

51

We are now two months away from our next Thunderdome. How are we doing in regards with the objectives set for that milestone? You may recall from my last post the objectives:

  1. have no timeouts with a cut-off at 9s;
  2. have an empty critical bugs queue;
  3. getting a slot free on our ‘Next’ queue.

We practically achieved the first objective! Today, we lowered the hard timeout to 9s and this didn’t increase our number of daily timeouts. We don’t have zero timeouts yet. We still have a fair bunch of timeout bugs to fix. But we get on average 650 requests timing out in a day. That’s less than 0.01% of our traffic.

Critical bugs filed in the last 7 days
These remaining timeout bugs are part of our second objective. On that front, we are in a more difficult position. We have 259 critical bugs to close. That went up since last time! What went wrong? Well, we had less people working on critical bugs for once. That’s been fixed this week when the Orange squad rotated back on maintenance. We again have two full squads working on critical bugs. Second, we modified our OOPS reporting to show all timeouts happening, not only the ones occurring the most often. That resulted in about 30 new timeouts filed. (See the hight red bar at the start of the graph). Fortunately for us, the rate of new critical bugs is declining.  We are at about 23 on average in the last two weeks. That’s still high and some of those are related to JS regressions escaping to production because our Windmill test infrastructure is disabled. This means that 51 is now the magic number. We need to close 51 of these critical bugs per week to reach 0 by the Thunderdome. That was the number we closed in our best week, just before the number of people working on criticals was reduced. So we’ll also need to reduce the number of new critical bugs found each week to succeed here.

Finally, on our last objective, like I already mentioned, the Orange squad switched back to maintenance. That’s because they completed the final bits of the project they were working on: Sharing translations between upstreams and Ubuntu. (Expect a blog post about it next week once everything is available to the general public.) That means that we need to complete 5 more projects to free a slot in our Next queue. That will be a stretch, but not impossible since of the two currently in progress, one should be completed in a couple of weeks and the other before the end of next month.  And two of the remaining ones are much simpler than what we have worked on until now.

I’ll post again next month to see how the final stretch looks like.

Photo by Aslak Raanes. Licence: CC BY 2.0.

1

Adding a PPA to Ubuntu — the GUI way

Published by Matthew Revell April 21, 2011 in PPA

On Monday I posted a video showing how to add a PPA to Ubuntu using a terminal.

And here’s a video showing how to do it using Ubuntu’s Software Centre.

2

Automatic bug expiry working again

Published by Matthew Revell in Bug Tracking, Notifications

Back in February, Martin wrote that we’d re-enabled Launchpad’s bug expiry feature. This meant that, if a project had enabled bug expiry, Incomplete bugs that appeared to be abandoned would be automatically marked Expired after 60 days.

This worked for a while and then broke. Normally, our monitoring scripts would have have alerted us to the problem but, by an unfortunate coincidence, a separate bug meant that the alert for bug expiry was also broken.

Both bugs are now fixed and bug expiry is working again. Shortly after the fix went live, Launchpad expired roughly 2,000 bugs that would have expired anyway over the past few months.
The option to enable bug expiry for a project

From now on, Launchpad will expire bugs in the usual way. A bug is a candidate for expiry if:

If you run a project and you’d previously had bug expiry set to on, but have decided you no longer want it, follow the Configure bug tracker link on your project’s bug overview page and then de-select the Expire “Incomplete” bug reports when they become inactive check-box.

Previous Entries
Next Entries