Matthew Revell talked to Ted Gould while at UDS-L in Dallas, November 2009.  Copying the notes here just for convenient access; check the thread for followups.

= Ted Gould =

'''Launchpad:''' [[https://launchpad.net/~ted|~ted]]

'''Usual location:''' Texas, USA

'''Role:''' Ubuntu X.org maintainer, employed by Canonical

== Edited Notes ==

Ted works on Canonical's Desktop Experience team and looks after Ubuntu's system status indicators.

He uses Launchpad constantly, primarily for bugs tracking, code hosting and the building of packages in PPAs. He also creates projects and releases.

To navigate Launchpad, he mostly URL hacks. He finds that the navigation in Launchpad has what he considers to be silly defaults. For example, when clicking on "Bugs" it shows you the bugs that were last touched. He'd much rather just see a list of bugs.

== Code hosting ==

He works on a lot of branches. Usually he has two branches per project: development and packaging. He develops on one and uses the other to prepare for submission to Ubuntu.

He puts the packaging branch in a PPA, for testing. His process is:

 1. Commit to the packaging branch.
 1. Create a merge request for the target Ubuntu desktop branch.
 1. Comments on what has changed and proposed Ken van Dine as the reviewer (default review team is his own team, which he feels doesn't make sense).

== PPAs ==

Ted builds the DX team's packages in the Canonical DX PPA for testing. The Ubuntu Desktop tean put packages in the formal primary archive. This can cause confusion because, if someone from the Ubuntu Desktop team makes a change to the package before uploading it, someone other than Ted may get an email about the package's build.

For example, if Ken van DIne changes the package it may well be that Ted doesn't find out that his package has been built and accepted for the Ubuntu primary archive.

Ted wishes that PPAs would keep older versions. He would like a configuration option that would enable them to say, "Keep older versions for X days." This would be great to help users bisect where a bug appears. Ted has filed a bug on this.

== Bug tracking ==

Ted generally knows that a bug is fixed because he's the one fixing it.

He uses the "Fix committed" status when the change has landed in trunk. He uses "Fix released" when the change has been released in the upstream project. He maitains a secnd bug tasks fort he Ubuntu package, though. Sometimes a bug is fixed released first in the package and then backported to the upstream.

Ted says the Bazaar project want to kill fix committed. Ted wants to keep it: it shows users that their bug is still there but fixed. Fix Released means the bug they've found may be different to this one.

Ted says that when a bug is marked "Fix released", we don't know what version that bug is fixed in. He says we can't rely on the bzr metadata because people misuse it.

Some bug tasks are less important than others -- a private packaging branch, for example, are not interesting.  Ted would rather have the option to ignore those or give them less prominence.

Similarly, some bug comments are more important than others. On a bug with 2,000 comments it's hard to know which are worth reading. If you have prior knowledge, you can identify the important commenters but most people can't and usually those bugs die.

Ted doesn't like that bugs can have only one level of duplicate marking. Unduplicating and then making a duplicate of another is very simple in the email interface but you don't have to go through 6 or 7 page loads and use several tabs if using the web UI.

He does almost all bug management using the email interface, as he can do it offline and finds the interface more sane. Also, he finds the web interface so slow that it makes bug work a pain. He gives the example of triaging a list of bugs by email, on a plane, and then sending the mail when he lands.

In some cases, he says it may be easier to invalidate a bug rather than unduplicate. He gives the example of two bugs that are duplicates of each other and also both bugs have ten other duplicates. He wants the option to make a bug a duplicate and to migrate all its duplicates to be duplicates of the new parent bug. It's hard to do that in Launchpad right now and undoing it would be even worse. Sometimes, community triagers can lead to multiple duplicates as they don't understand that two bugs are just the same problem manifesting in different ways.

Threading is main thing that Ted feels is missing from bug reports. He can't track the forking of a bug discussion and so the comment history may be confusing. He understands that the argument is that it shouldn't happen but it does! He finds it Odd thing is that code reviews *are* threaded but bug comments aren't. Why's that? Perhaps it's because passionate users don't necessarily know what they're talking about.

== Code hosting and review ==

Ted would like to have the option to specify who must review and/or how many people need to review a branch before a merge can land.

He does almost all code review in the email interface for the same reasons he gave for using the bug email interface.

== Using other tools with Launchpad ==

Ted's team's focus is upstream -- they do packaging only so they can install and test their own work. They use a continuous integration tool called Hudson, which monitors for changes in a branch. When it sees the branch cahnge, it pulls it down, builds it and, if it passes ''make check'', it builds a source package and uploads it to the team's PPA.

Hudson is linked to a private Twitter feed that notifies them of build news.

Ted has spent hours trying but has never managed to upload using git. Using git is a problem.

Ted uses lots of tools with Launchpad: Bazaar, the Debian packaging tools, Launchpad review notifier (uses the API), Hudson, and Bug Hugger a little.

== Projects ==

Ted manages what he calls an umbrella project -- a project group. He struggles to find the milestones for that umbrella project in the web UI. So, he URL hacks instead. In the DX team, they have one project group for public projects and another for private projects.

He says that it's silly for Launchpad to complain of a lost page when you try to visit a milestone page that doesn't exist. Instead, it should tell you that the milestone doesn't exist.

In the DX team they have twelve sub-projects and seven staff, so they share the responsibility for sub-projects. Using the umbrella project, they can ensure they don't miss anything.

== Collaboration ==

Sometimes they collaborate with upstream teans but always on their terms. For example, they may be patch gtk and then put that patch in Bugzilla. They don't do it in Launchpad.

Ted's team patched Empathy to use libindicate. There was a lot of conflict because Empathy didn't want the patch and also it had some bugs. It was difficult to manage fixing the bugs because it was in git.

Ted couldn't see how Launchpad pushing patches directly into upstream git or code review would make their lives much better.

Ted says that collaboration using Launchpad works but it's not as good as sitting in the same room. He doesn't see how it's more collaborative than other similar tools.

IRC is important for discussion but bug reports are the artefacts that stay around so Ted tries to ensure that he keeps those up to date, particularly public-facing bugs. Ted said that he sees IRC as crucial to collaboration.

He says the best thing to do for collaboration would be to have federated Launchpad. If we don't federate, we'll still see people installing local Launchpads but we'll lose those bugs.

== Other areas ==

Ted loves email interface: it really great offline but would love to see a standard offline interface.

He really likes the simplicity of the bug workflow and feels Bazaar branches work well, although he'd like a repository view. He says there's no way to say how two branches are related and that it's hard to see what version someone has branched from and whether they've made merges back in. Clearcase has a great repository view. Perhaps a restriction of Bazaar is that it's branch based.

He's pretty pleased with code reviews, although automatic branch landing would be huge for them.

When someone first starts using Launchpad, getting peolple into teams and then setting them up towork is hard. It doesn't seem reliable for getting people onto mailing lists when they join a team. Crazy hierarchy of teams is difficult to maintain. Can't see a good way to manage that.

There's no way to give packagers upload rights without making them drivers.

He doesn't know translations but feels he does know the rest of Launchpad.

Ted uses Google to search for things in Launchpad.

== Raw Notes ==

{{{
Ted works for Canonical on the indicators -- system status in Ubuntu.

Ted uses LP constantly -- all code hosting, all build (PPA service) of
packages. Personally, create projects, do releases. Most important
thing: code hosting and builds.

Mostly URL hacks. Doesn't navigate because it has silly defaults. Bugs
-- first thing it shows you are the bugs that were touched last/hot
bugs. Most useful is the list of bugs. Mostly uses history from URL
bar.

Use Launchpad for a lot of bugs. Doesn't like it -- having bugs, that is :)

Code hosting for indicator-applet: work on lots of branches. Two
branches per project: development and packaging. Develop on one,
prepare one for submission to Ubuntu.

Work on both at the same time. Put the packaging branch in the PPA.
Commit to the packaging branch, create merge request for target Ubuntu
desktop branch. Request merge, comment on what's changed, propose ken
Van Dine as the reviewer because your default review team is your team
-- not sane. Should be Ubuntu Desktop team. Ted is a member of the
Ubuntu Desktop team. Technically Ted could commit to it directly.

Build their stuff Canonical DX PPA for test building. It's the Ubuntu
Desktop team who actually put it in the formal primary archive.

So the last person named changes file gets the email from the primary
archive. So, if Ken changes the package it may well be that Ted
doesn't find out that his package has been built in and accepted for
the Ubuntu primary archive

It becomes difficult to notify people that their package hasn't made it.

Ted wishes that PPAs would keep older versions. Would like a
configuration option that would enable them to say, "Keep older
versions for X days." This would be great to help users bisect where a
bug appears. Ted has filed a bug on this.

Knows that a bug is fixed that he's filed because often he'sthe one
who's fixing it!

Use fix committed: landed the fix in trunk. Fix released -- released
as upstream. Have two bug tasks -- one for Ubuntu package and one for
upstream/ Sometimes the package bug is fixed released first and then
backported to the upstream.

bzr want to kill fix committed. Ted wants to keep it -- he feels
strongly. Fix commited shows users that their bug is still there but
fixed. Fix Released means bug they've found may be different to this
one.

When a bug is marked fix released, we don't know what version that bug
is fixed in. Can't really use the bzr metadata because people misuse
it.

Some bug tasks are less important than others -- private packaging
branch, for example, are not interesting. Debian packaging tools marks
that branch as fixing a bug but that doesn't mean that's where the fix
appeared.

Workflow between working on an upstream and on the distro is huge.
Development branches versus source code branches.

Dev branches -- core of the source code, do code reviews. Package
branches -- does it install in the right place, did it break an
API/ABI, and so on?

Ted's team's focus is upstream -- they do packaging only so they can
install their own work. Allows them to do testing. Their test builds
are built outside of Launchpad -- they have a hudson instance.

hudson sees a change in a branch, pulls it down, builds, and then if
it builds and passes make check it'll build a source package and then
uploads it to the PPA. Continuous integration system.

Twitter feed -- Bob The Builder.

Sometimes collaborate with teams upstream but on their teams. Patch
gtk -- and then put that patch in Bugzilla. Don't do it in Launchpad.
But we won't automatically alter their bug database. Pushing patches
directly into git and the code review tool in Bugzilla wouldn't really
make their lives that much better.

Cody uses git. Ted has spent hours but has never got it to upload!
Using git is a problem.

Ted's team patched empathy to use libindicate. There was a lot of
conflict because empathy didn't want the patch and also it had some
bugs. It was difficult to manage fixing the bugs because it was in
git. Asked Ted to explain more.

Ted uses lots of tools with LP: bzr, the Debian packaging tools,
Launchpad review notifier (uses the API), hudson, bug hugger a little.

They require a single code review, whereas U1 requirse two so they may
want more. It'd be nice to have the option to specify who must review
and/or how many people need to review before a merge can land.

Does almost all bug management using the email interface. More sane.
LP is so slow that it makes bug work a pain in the web interface. It's
offline! Can do it on a plane and then send when lands.

Code review in the email interface for the same reasons.
Bugs can only be one level of duplicate. So unduplicating and then
making a duplicate of another is very simple in the email interface
but you don't have to go through 6 or 7 page loads and use several
tabs if using the web UI.

It may be easier just to invalidate a bug rather than unduplicate. Say
you have 2 bugs that are duplicates of each and each has 10 bugs. It's
hard to fix that. Make this bug a duplicate and migrate all its
duplicates. Undo would be a pain! Sometimes community triagers won't
understand that something is really the same bug because it seems to
manifest in a different way.

Another thing that Ted does is managing an umbrella project. Can't
find the milestones for the umbrella project in the UI. Has to URL
hack. Lost page is a silly thing to say when you try to visit the page
of a milestone that doesn't exist -- it should tell you, even though
Ted is sure because he has learnt that that's what happens when he
mistypes the milestone URL.

They manage their bugs using milestones. They have around 12
sub-projects in the umbrella project but only 7 employees. Using the
umbrella project they can see all the projects. They use the umbrella
project view so they don't miss anything.

Collaboration using LP works -- not as good as sitting in the same
room. Threading is main thing missing from bug reports. Can't track
the forking of a bug and so the comment history may be confusing.
Argument is that it shouldn't happen but it does! Odd thing is that
code reviews *are* threaded but bug comments aren't. Why's that?
Perhaps it's because passionate users don't necessarily know what
they're talking about.

On a bug with 2,000 comments it's hard to know which are worth
reading. Usually those bugs die. But you can usually scan through and
look for the key players and read their comments. No special marking
of who is a key player. Have to have prior knowledge.

IRC is important for discussion but bug reports are the artefacts that
stay around so Ted tries to ensure that he keeps those up to date.
Particularly public-facing bugs, he tries to keep them up to date.

Has used Sourceforge.

LP as collaborative tool -- it's no more collaborative than other
tools. The email interface is the strongest feature but other tools
have that. Likes LP but doesn't see how it is more collaborative than
other tools.

How could it be more collaborative? Nothing specific. Updated diffs on
code reviews was key. Can't think of specific friction points.

Best thing to do for collaboration would be to have federated
Launchpad. If we don't federate, we'll still see people installing
local Launchpads but we'll lose those bugs.

Loves email interface -- works really great offline but would love to
see a standard offline interface. Loves simplicity of the bug
workflow. Bzr branches work well -- missing a repository view. No way
to say how two branches are related. Hard to see what version someone
branch from, whether they've made merges back in. Clearcase has a
great repository view. A restriction of bzr is that it's branch based.

Code reviews -- pretty pleased with them now. Automatic branch landing
would be huge for them.

Interview Cody Russell.
(NOTE: we did, see Strategy/RawData/CodyRussell.)

When someone first starts using LP, getting peolple into teams and
then setting them up is hard. It doesn't seem reliable getting people
onto mailing lists when they join a team. Crazy hierarchy of teams is
difficult to maintain. Not a good way to manage that.

No way to give packagers upload rights without making them drivers.

Doesn't know translations but otherwise feels he knows it.

Uses Google to search for things in Launchpad.
}}}