Usual location: West coast USA
Role: Ubuntu packager and WINE project member
Scott's use of Launchpad
Scott is an Ubuntu packager, mostly for the WINE project. He uploads packages and is subscribed to all bugs reported in Launchpad against the WINE project and Ubuntu WINE package.
He also uses the WINE project's Bugzilla bug tracker, although they're looking to change to Redmine as that can link to git code commits and also has wiki features. They'd like to have one login for everything.
Triaging and upstreaming WINE bugs from Ubuntu
Scott's main task in Launchpad is to look at bugs reported against Ubuntu's WINE package. If it's a packaging bug, he fixes it.
If it's an upstream WINE bug, he first ensures that the bug report is complete. If it isn't something that the upstream develoeprs could act on, he'll ask for more information.
He then checks that the bug is not already in WINE's Bugzilla by searching for similar terms. If it appears to be a new bug, he copies the description from Launchpad, pastes it into WINE's Bugzilla and then links to the Launchpad bug. He then leaves it for the upstream developers to fix as he does not hack on WINE code.
A button to push the bug, plus comments, upstream would be useful, especially if it was limited to Scott and other trusted people.
He finds out about new bugs reported in Launchpad as he has a structural subscription to the WINE package and the WINE project in Launchpad. He also often looks at the bugs listing page.
When he's triaging bugs, he uses the "Triaged" status to mean that he's liked the bug to one upstream. He also checks "Incomplete" bugs and, if they've had that status for a while, will mark them "Invalid".
Every once in a while he'll use Advanced Search to filter out all the "Triaged" and "Fix Released" bugs. That lets him see those that he needs to fix at his end.
If upstream WINE closes the bug upstream, he'll see the status change in LP and get an email from LP. He can then see what the change is and create a new Ubuntu package of WINE. He'll put the bug number in the package and LP will mark the bug as fix released when the package goes live.
He has a simple way of filtering bug related mail: he filters all email that has the word "bug" in the subject line. Scott mentioned that Bugzilla and Launchpad bug mails use almost the same subject line and suggested that Launchpad should differentiate its bug mail subject lines.
He gets frustrated at receiving bug mail when someone adds a Baltix bug task to one of the bugs in WINE. He believes that it's best to ignore any bug mail to do with Baltix as, in his view, Baltix doesn't do anything that would be useful to him and so he'd like the option to block all mail related to Baltix.
Scott's use of PPAs
Every two weeks, Scott downloads the WINE source code and puts out a new package in the ~wine-team PPA. He's the only active member of that team.
If a package fails to build, he'll get an email. If it builds, it'll appear in update-manager and he'll get a notice to update.
The falure email has a weird subject line -- "Release". In this case, "release" means the package failed to build, which seems odd. Despite that, Launchpad is great at telling him when builds fail. That email prompts him to go to the PPA and look at the build log to see why it failed.
Before PPAs were released, he used an external repository to put out those fortnightly packages. In time, between 60,000 and 100,000 people were using that repository so even after PPAs came about he continued with it as it would have been hard for people to move over. Also, it was easier for people to get the key used on the third party repository than the PPA's key.
He still uses that third-party repo for distro releases before Karmic and simply copies over the packages built by the PPA. For a while, he used LP as a glorified build demon. However, with easy PPA addition and the planned integration with Software Centre, he sees PPAs as the future for WINE's fortnightly build packages.
It's also good that anyone in the ~wine-team can upload packages too, and that other people can use his PPA to make their own builds with minimal efforts. One person tracked his builds for a while but applied a particular patch and then built them in his PPA.
Scott also emphasised that the PPA support for multiple architectures is a real benefit. For several months, he couldn't produce 64-bit packages as he didn't have a 64-bit machine. PPAs fix that.
Adding PPAs has improved in Karmic to such an extent that Scott has begun phasing out the third-party repository to use the PPA exclusively. However, he is not sure that this has been the best move for two reasons:
- He's concerned that the PPA deletes older versions of packages as many people want to try older packages to help with regression and bug testing.
- Also, sometimes the automatic key import doesn't work and then it never tries again.
With regard to deleting older versions of packages, Scott says:
- "A substantial number of Wine (beta) users depend on older versions as the newer ones may have broken. If they're on Karmic I currently have nowhere to point them." That is because he's using the PPA for Karmic and his third-party repo, where he can keep older packages, for pre-Karmic.
With regard to the automatic key import, Scott says:
- "Some chatting in IRC reveals that this may be an issue with the keyserver being unavailable -- after the key isn't found immediately, software sources never tries again.
- "It's not quite launchpad code, but some work does need to be done client side to make this actually usable (eg LP should ensure a working keyserver, and there should be an error message when it fails to get the PPA key)."
Working with teams
One problem that he came across when working with teams was that the Ubuntu WINE team originally had an open policy. 150 people joined but most of them did nothing. When Scott came to set up the PPA, he had to remove everyone else from the team as he didn't want someone he didn't know randomly uploading a bad package.
While doing that, he noticed and reported bug 444760: Scheduling a team member's expiration is off by one.
Scott doesn't use translations as WINE doesn't use GetText for translations yet. They want to tap into the Rosetta community so they're converting WINE upstream to GetText to be able to use LP for translations.
One worry they have is that WINE wants individual attributions for each change they make. If Scott changes a string in Rosetta and put it into Wine, they want to be able to index each string to an individual git commit.
This is so they can blame people who copy text from Windows itself! They might have to create a restricted translations team but that defeats the point because they want to tap into the community.
To Scott, Launchpad aids collaboration by providing organisation for all the messages that a community's members want to send to each other,
In theory, they could do that in email but Launchpad helps them manage it by providing comment histories etc.
Launchopad isn't so much about collaboration with other develoeprs but maybe contacting users and also building his packages. It's not really a collaboration tool so much for Scott but more a publishing agent.
He doesn't know how LP could be more collaborative. He thinks Bazaar works very well as a collaboration tool: branching, patching and merging.
Scott often uses people's profile pages in Launchpad to find out how to get in touch with them. He doesn't look at karma that often but may look at a stranger's karma page to get a feel for their activity but does not use the karma number itself.
Scott has used other bug tracking tools that are similar to LP but has never used anything like PPAs. He has heard about OpenSUSE's build service but hasn't looked at it.
He feels he knows LP well -- has filed bugs against LP itself. He uses PPAs, has explored MLs but doesn't use, understands package submission and building, uses all the bug tracking features and owns a PPA for a game called Spring. It's a multi-player game, everyone has to have the same version for the game to sync. To play Spring, people add the Spring PPA and whenever there's a new release one of the Spring team uploads a package to the PPA.
He had to manually ask for a larger PPA because the game Spring is huge. Each Ubuntu release requires more size.
It would be nice if LP's Bazaar features could be used with upstream git trees. So, he'd like to have the equivalent of anything that they have in bzr branches work with git branches: merge proposals, "give me this build as a package" and so on.
From: Matthew Revell Subject: Launchpad user testing: Scott Ritchie rough notes Date: Wed, 18 Nov 2009 17:25:03 +0000 As before, these are as I type them. Expect spelling mistakes. I'm sure Scott will email us if I've misrepresented him at all. [[[ NOTE: Updated on 2009-12-03 to include clarifications and corrections from Scott Ritchie's followup, so what's below is not precisely what Matthew originally posted. ]]] Scott Ritchie Scott is a packager mostly for universe. He uploads packages and is subscribed to all WiNE related bugs. He has a folder for bugs in his inbox that catches all LP bugs and Bugzilla bugs from his upstream projects -- WINE. His filter looks for "Bug" in the email subject. Uses LP's autosubscribe to all WINE and WINE package bugs. Upstream at WINE HQ they have their own bug tracker -- Bugzilla -- may migrate it. Reason: Bugzilla can't link to git branches or other things. Discussion of setting up Redmine that can link to git code commits. Also has wiki features. Be good to have as they would have one login for everything. Scott's tasks with LP is to look at bugs reported against WINE in Ubuntu. If packaging bug, he fixes. If a WINE bug, he copies and pastes into Bugzilla and then links from the LP bug. Someone goes to WINE in LP and reports a bug. Scott gets an email because he's subscribed. The email is how he finds it but he also often looks at the bug listing page too because all the bugs need to be dealt with eventually. In LP on the bug page he can see all the bugs with their statuses etc. If a bug has triaged status it means he's linked the bug to an upstream bug. If upstream WINE closes the bug upstream, he'll see the status change in LP and get an email from LP. He can then see what the change is and create a new package. He'll put the bug number in the package and LP will mark the bug as fix released when the package goes live. If Scott goes to the summary list of bugs in LP, he'll look at incomplete bugs and if they haven't been updated in a long time he'll mark them invalid. Every once in a while he'll use Advanced Search to filter out all the triaged and fix released bugs. That lets him see those that he needs to fix at his end. When he sends a bug upstream he basically just leaves it and says "Do it!" He doesn't work on the code itself, he does website work (English), docs and packaging. He doesn't do C code. He does front end work, packaging, etc. When he's upstreaming a WINE bug, he has to avoid posting duplicates to WINE's buzilla by searching in that bugzilla for similar sounding bug reports. Part of his task with WINE is to be a filter for bug reports. If someone doesn't have a usable LP bug report, he asks for more info before he ever sends it upstream, so he can ensure the WINE people don't have to worry about dealing with poor quality bug reports. Every two weeks, he'll d/l the WINE source code and put out a new package in a LP PPA. PPA for Ubuntu WINE team is really just Scott. Couple of years ago someone created a LP WIne team and around 150 people joined but Scott was the only one doing any work. At the time, PPAs were new. They really helped WINE. Every two weeks WINE puts out a new release. Can't update that for production as those releases are not guaranteed to be regression free. However, people can follow fortnightly releases using the PPA. Before PPAs existed they set up a third-party repo. 60,000 - 100,000 were using that third-party repo for fortnightly releases. Even after PPAs came about, they continued with the third-party repo as it was hard for people to move over. And it was easier to get the third party repo key than the PPA key! It's improved in Karmic and so Scott has decided to phase out the third-party repo. If you want to install the latest WINE beta in karmic, go to the WINE website and then you type "ppa ubuntu/wine/ppa" and that should add the Ubuntu WINE PPA and the key automatically. [[[ Scott later added: "As I noted I'm not sure this has been the greatest change due to the key issue and the lack of an archive history." Meaning, switch from third-party repo to PPA has maybe not been functionally a complete win for them. Hmmm. ]]] Sometimes it doesn't seem to get the key but it'll add the repo. If the key server is busy, it'll fail to get the key and never get it. Whoever's running the keyserver needs to make sure it stays available. [[[ Scott later added: "Some chatting in IRC reveals that this may be an issue with the keyserver being unavailable - after the key isn't found immediately, software sources never tries again. It's not quite launchpad code, but some work does need to be done client side to make this actually usable (eg LP should ensure a working keyserver, and there should be an error message when it fails to get the PPA key)." ]]] Every WINE release he'd upload to the WINE team PPA and make a release for each different Ubuntu version. He uploads the package using dput. If it fails to build, he'll get an email. If it builds, it'll appear in update-manager and he'll get a notice to update. Falure email has a weird title -- "Release". Release means failed to build. That's weird. He'll go to the PPA and look at the build log. He'll see why it failed. Scott now needs to take the packages built in the PPA and put them in the third-party repo. LP in the package details listing will provide direct links to the debs. He then copies each link location and pastes them in GEdit. Once everyone's using PPAs he won't have to do this any more! [[[ Scott later added: "Specifically I run 'wget [long list of links copy/pasted from gedit off launchpad]' on the server." ]]] Third-party server still has a lot of users. He can't move them instantly to the PPA. So, he gets all the debs and dsc and diff.gz files. This can make a release take an extra day or two to get to people. He also needs the changes files. He then logs into his server and wgets the links. He has a new build of WINE 1.1.33, he moves it into a folder on the third party repo server. Launchpad doesn't offer him an archive of all the older versions of packages. He does have that on the third-party repo. It's useful for users -- sometimes users need an older version of WINE because the current version has a regression. It's a shame to lose that package history in PPAs. A substantial number of Wine (beta) users depend on older versions as the newer ones may have broken. If they're on karmic I currently have nowhere to point them. Last step is to edit a text file -- the webpage of the server -- and adds a link to the latest version. For a while, he used LP as a glorified build demon. However, it's now the future. Easy addition of PPAs and integration with Software Centre is gonna be great. Despite the awkward email subject (releaes) LP is great about telling him when there's a build failure. It's good that other people in the Ubuntu WINE team can upload packages to that PPA. Even tho' he's fine doing it himself right now. Another use did follow the PPA and make his own builds with a particular patch and use it in his PPA. Before PPAs he used to build it on his own machine using pbuilder envs for each release. Advantage that LP builds for different architectures at the same time. Now he doesn't have to have both 32 bit and 64 bit computers. (Building manually was a real pain. At one point we didn't have 64 bit Wine packages for months because I didn't really have a 64 bit computer.) LP provides same build env as distro, so doesn't have to worry about his laptop env. LP is quicker than builder on his own machine. Sometimes LP takes longer around release day. [[[ Scott later added: "Not that anyone will mind, since downloading takes about 10 times as long too." ]]] Has used other bug tracking tools similar to LP but has never used anything like PPAs. Has heard about OpenSUSE's build service but hasn't looked at it. One particular prob with the Ubuntu WINE team -- when there was a 150 people in it (casual people) he wanted to be able to have some members who had PPA permissions. Instead, had to kick out everyone else. Didn't want some random person uplkoading a bad package to the team PPA, so had to remove all the other members of the team. Very annoying -- had to remove each one one at a time. [[[ Scott later added: "This revealed a small bug: https://bugs.launchpad.net/launchpad/+bug/444760" ]]] Occassionally gets mails for bugs that have been fixed released, because he's subscribed to all bugs in Ubuntu WINE, but he'll get a mail when a bug is fixed in Baltix because it has a bug task but Baltix never really does anything so it'd be better to just ignore Baltix! One bizarre thing is the way that LP tags its bug mails is almost the same as Bugzilla. Can tell apart the WINE bugzilla ones because they have smaller bug numbers! Might be interesting to put "LP Bug number" rather than just "Bug number" in the bug mail subject. (Specifically, right now it's "[Bug: 12345]" for Bugzilla and "[Bug: 123456]" for LP!) There is now a WINE 1.2 package which is different to the WINE package. 1.2 packages has the latest beta that was available at the Karmic release. In software centre you see both. There's a separate LP bug page for both packages but there tends to be a lot of overlap for them They're in two places. He doesn't see how it can work any better than it does right now but when he created the 1.2 package he had to resubscribe to bug mails for the new package. One complaint is that some of the bugs have been fixed upstream. There's no way for him to say it's fixed in WINE 1.0 if you d/l the 1.2 package. He could file a bug task and say it's He had to make a wiki page explaining what the different LP bug statuses meant for WINE. It follows the LP conventions more or less. So doesn't really matter. He feels he knows LP well -- has filed bugs against LP itself. Uses PPAs, explored MLs but doesn't use, understands package submission and building, uses all the bug tracking features, owns a PPA for a game called Spring. It's a multi-player game, everyone has to have the same version for the game to sync. To play Spring, people will add the Spring PPA and whenever there's a new release one of the Spring team wll upload a package to the PPA. Spring is in Karmic. Had to manualy ask for a larger PPA because the game Spring is huge. Each Ubuntu release requires more size. Doesn't use translations. WINE doesn't use GetText for translations yet. They want to tap into the Rosetta community so they're converting WINE upstream to GetText to be able to use LP for translations. One worry they have is that WINE wants individual attributions for each change they make. If Scott changes a string in Rosetta and put it into Wine, they want to be able to index each string to an individual git commit. Wnat to be able to blame people who copy text from Windows itself! Might have to create a restricted translations team but that defeats the point because they want to tap into the community. Collaboration in LP means that it's organisation for all the messages they're sending to each other. In theory, they could do that in email if they had something to manage that. Well, that's LP. The value in going to LP is seeing the comment history on a bug and that's collab. LP isn't so much about collab with other develoeprs but maybe contacting users and also building his packages. It's not really collab but a publishing agent for him. He doesn't know how LP could be more collaborative.bzr works very well at collab. Branching, patching and the merging in is collaboration. LP's social page --- will look-up someone on LP and find out how to get in touch with that person on their LP profile page. Doesn't often look at karma. May look at a stranger's karma to see what they do but it's not a reliable number for knowing how much they do. A button to push the bug, plus comments, upstream would be useful. Esp. if limited to Scott and other trusted people. It would be nice if LP's bzr features could be used with upstream git trees. Be nice if he coul;dhave the equivalent of anything that they have in bzr branches work with git branches: merge proposals, "give me this build as a package" and so on. One thing they've discussed at WINE HQ: when they move to redmine, they could create different trees for Ubuntu packages.