Bryce Harrington appointed Ubuntu Launchpad stakeholder representative
Published by Francis J. Lacoste June 4, 2011 in General
When I explained how we determined what feature to work on next, I mentioned that we were looking to add a stakeholders representative for the Ubuntu project. Well, it’s now done. The Ubuntu Technical Board delegated Bryce Harrington to that position.
So if you are part of the Ubuntu community and need something from Launchpad, you can now talk to Bryce.
I’m really glad to have him on that position. Not only is he a respected member of the Ubuntu community, but he also did a 6 months rotation within the Launchpad team, so has understanding of how our project operates.
He’ll now be in a position to escalate important bugs affecting the Ubuntu community, as well as present the community’s view on what new features should be prioritized. It won’t be an easy job, since the Ubuntu project is big and varied. The people who cares about bugs are often not the same that cares about translations nor the same that cares about package publishing or the Ubuntu distribution development toolchain. And the stakeholder representative job is to help prioritize these needs to make sure that the Launchpad team works on the most important work. Plus then he’ll have to find common grounds with the other stakeholder representatives!
Thanks Bryce for stepping up to these responsibilities!
Photo by Wally Gobetz. Licence: CC BY-NC-ND 2.0.
What does rotation to maintenance really means?
Published by Francis J. Lacoste June 3, 2011 in General
I’ve been asked this question privately a few times already. What does it mean for a squad to rotate from feature-mode to maintenance-mode? The question arises as a number of folks noticed that some members of the squad continue working on feature-related bugs after they are on maintenance shift. That happened with the former Blue squad when they completed daily builds, with the Orange squad when they completed sharing translations, and with the Yellow squad and better bug subscriptions. So let me clarify what that boundary means.
In a nutshell, it means that the squad starts new work from a different queue. After the switch, new work will come from the general maintenance queue. Because we do the switch aligned with the calendar week, there is always work related to the feature that is still in-process (code started but not reviewed, or landed but not deployed, etc.) That’s the work that continues after the transition. After the rotation, the squad also becomes on the hook to cater for the user support duties related to maintenance mode.
What are the trade-off related to this boundary definition? The main impact is that we get a dip in maintenance related bug fixes around the rotation. That’s because the new maintenance squad has still some members not ready to start new maintenance-related work. It could be argued that because of the interrupt nature of the maintenance responsibilities, it would take longer to finish off the work related to the feature. I’m not sure that happens in practice, but I make note to check the data…
The alternative would be to only rotate after all the feature-related bugs are done-done. The rest of the squad could fix some lower priority bugs related to the feature or clean-up tech-debt accumulated during their rotation. It would preserve the number of people effectively working on maintenance around the transitions. But it would mean that it would take longer before we start the next feature. And given the poor state of our feature cycle time, it’s not a trade-off that I (and I guess our stakeholders) would be willing to make at this time. We might revisit this in the future though.
Photo by Camilia Hoel. Licence: CC BY-NC-SA 2.0.
Launchpad read-only June 8th 22.00 UTC
Published by Matthew Revell June 2, 2011 in Notifications
Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 22.00 UTC on the 8th June 2011. This is to allow for our monthly database update.
Starts: 22.00 UTC 2011-06-08
Expected back by: 23.30 UTC 2011-06-08
Guessing relevant test modules with Fault Line
Published by Aaron Bentley in General
Launchpad’s test suite takes a long time to run. Far too long to wait for when you’ve made a change. And the likelihood that you’ve broken any given test is pretty small. So you probably want to start by running the tests that were likely to break.
You can usually guess which tests to run; if you’ve changed “archive.py“, you should probably run “test_archive“. But some connections are easier to miss, so I’ve hacked up a Fault Line, a bzr plugin that uses past changes to guess which test files correlate to the files you’ve changed. You can run it like so:
bin/test -m $(bzr fault-line --module-regex)
This will look at all the files you’ve changed, look at their recent history, and see which files tended to change in the last 100 revisions where you changed the specified files. The --module-regex option causes it to output a regular expression, assuming that the test files are Python modules. Otherwise, it would just output a list of the test files it found.
Thanks to Jelmer Vernoij, this is even easier to achieve for testing bzr. You just need to run “bzr selftest --auto“.
To install Fault Line, just run:
bzr branch lp:fault-line ~/.bazaar/plugins/faultline
It currently requires bzr 2.3 or later (e.g. stock Natty bzr).
Fault line is pretty limited right now. For example, the way it guesses what’s a test file is hard-coded. But a few days ago, it wasn’t even a proof of concept. Who knows what the future holds?
team owner no longer implies team member
Published by Robert Collins May 31, 2011 in Coming changes
A short headsup about an upcoming change.
A very long time ago the team owner was always a team member. This was changed to make team owners optionally members (sometime before 2008!). However the change was incomplete – there has been an inconsistency in the codebase ever since. For the details see bug 227494.
I wanted to let everyone know about us actually finishing this change though, because for a small number of teams (about 400) their administrators may be surprised when they cannot do things.
The inconsistency was this: if a team owner leaves the team, so they just own it, then they are not listed as a team member. But if they try to exercise a privilege the team grants – e.g. if the team is a bug supervisor – the team owners were able to do this. This setup made it impossible for users to accurately determine who can carry out the responsibilities of a team : the Launchpad web UI incorrectly reported team members.
The fix which will be deployed in the next day or so corrects this inconsistency: Team ownership will no longer grant access to anything that team membership grants.
For clarity, these are the rules around team owners:
- When a team owner is assigned (or a team made) the owner defaults to being an administrator-member.
- If a team owner deactivates their team membership then they are not considered a team member anymore: resources and access that team membership grants will not be available to the owner at this point.
- Team owners can always perform adminstrative tasks on the team: creating new administrators, edit the team description, rename the team etc.
- Point 3 allows an owner to add themself to the team they own even if they deactivated their membership previously.
Countdown to the pie
Published by Francis J. Lacoste May 27, 2011 in General
We are now one month away from the Dublin Thunderdome and the stakes of the game have increased substantially since last time! At UDS, Jonathan announced he was willing to take a pie in the face if we achieved our 0 critical bugs goal. Two others joined him in the bet.
As of this writing, we have 210 critical bugs left to fix to pie Jono, Ted and Neil. (203 actually, since 7 of those are bugs escalated after the bet announcement.) Unfortunately, their face seems pretty safe :-/ If we look at the trend of the last 4 weeks, we see that we are burning down about 12 bugs per week. At this rate, we would achieve this goal in 18 weeks, so around the end of September. 3 months too late for a pie! This week, the Yellow squad is starting on maintenance, so we’ll see if they can improve on the 12 bugs a week burn-down. I mean, that number is 3 times the long-term rate which is more like 4 a week, so we are definitively improving! Both because we are better at fixing bugs, but also because the number of newly found issues is declining. You can see the combined effect of this on the burndown graph as the slope gets much sharper on the right.
It doesn’t look much better on our third objective which is to have a free slot in the stakeholders Next queue. This week the Teal squad resumed work on the our project to improve Launchpad privacy features. They did an initial break-down of the project and they have work until the next UDS! The Red squad is finishing off derived distributions, probably before the Thunderdome. But even then, at that point we would be starting on adding customizable columns on search results. And the Next queue would still be full at 2 items. On the plus side, we won’t be over our work-in-process limit anymore 🙂
I’m looking forward to see how this all turns out in Dublin, but whatever happens, at the very least, we’ll have succeeded early on our 9s timeout objective.
Photo by David Muir. Licence: CC BY-NC-ND 2.0.
Tilde or not tilde
Published by Matthew Revell in General
When Launchpad shows someone’s display name, it’s not always clear who it’s referring to.
With so many people registered in Launchpad, it’s not surprising that some of them share a name. However, every Launchpad id is unique. Mine’s matthew.revell and no matter how many other Matthew Revells there might be in Launchpad, I’ll always be the only one with that ID.
To help clarify who’s who, we’re going to show the ID in more places alongside the display name. Two of those places are the person picker — so you know for sure that you’re selecting the right person — and at the top of the profile page.
There was some discussion, though, as to whether people would recognise that we were showing the person’s Launchpad ID. One way to make it clearer, it was suggested, would be to place a tilde in front of the ID.
On Wednesday I set up a survey asking which of these you prefer:
And which of these you prefer:
Rather than say it straight out — i.e. do you like the tilde? — I wanted to see if people noticed it.
The majority of people who responded to the survey said they preferred the versions without the tilde.
For the person picker, 23.6% of the respondents preferred the version with the tilde and 76.4% preferred the version without.
For the profile page it was a little different and even more in favour of the version without the tilde: 18.4% preferred the version with the tilde, whereas 81.6% preferred the version without.
Thanks to everyone who took part. It’s now over the to Teal Squad to digest the results.
Photo by Fling Poo. Licence: CC BY 2.0.
Help us test something new!
Published by Matthew Revell May 25, 2011 in General
My colleagues in the Teal Squad have been working on a small change that’ll make it easier to distinguish Launchpad users who have similar names.
We’ve got two quick questions in our new survey. Help us make it easier to tell who’s who in Launchpad.
The survey is open for 24 hours only, so get in before 18.00 UTC on the 26th May.
Take our short survey to help us make it easier to tell who’s who in Launchpad!
Photo by Elizabeth M. Licence CC BY 2.0.
Congrats, nigelb and chrisjohnston!
Published by Martin Pool May 23, 2011 in General
Congratulations and virtual cupcakes to nigelb and chrisjohnston who got their first changes in to Launchpad, and to the reviewers who helped get them finished off and deployed.
jml said it so well at his recent short talk:
(update: fixed mysteriously-broken video start-at time.)
Coming soon: improved bug subscriptions
Published by Matthew Revell in Bug Tracking
Did you know we’re running a beta of Launchpad’s new bug subscriptions system?
If so, you may have heard that we were planning to take the new subscriptions system out of beta today.
There are, though, a couple of bugs that we want to fix before taking the new bug subscriptions system live. And one of those bugs requires an update to our database, which means a short amount of read-only time for Launchpad.
So, we’re now planning to make the new bugs subscription system live on June the 8th, which is our next scheduled database roll-out.
If you want to start using the new system straight away, join our beta team!
Photo by Jordiet. Licence: CC BY SA 2.0.
