Strategy/RawData/ScottRitchie

Not logged in - Log In / Register

Launchpad: ~scottritchie

Usual location: West coast USA

Role: Ubuntu packager and WINE project member

Edited Notes

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:

With regard to deleting older versions of packages, Scott says:

With regard to the automatic key import, Scott says:

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.

Translations

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.

Collaboration

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.

And also...

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.

Raw Notes

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.

Strategy/RawData/ScottRitchie (last edited 2009-12-09 05:12:00 by kfogel)