Proposed changes to workflow bug management

Ben Collins ben.collins at canonical.com
Mon Jun 2 17:04:23 BST 2008


On Mon, 2008-06-02 at 12:17 -0300, Christian Robottom Reis wrote:
> On Mon, Jun 02, 2008 at 08:53:35AM -0400, Ben Collins wrote:
> > I don't see that as being true. First off, it's not assigned to the team
> > until it is triaged and secondly, before it is triaged, it can be
> > assigned to the triager.
> 
> Well... assignment, in Launchpad, means "the person who is responsible
> for fixing this bug". While today the UI may make that not such a hard
> constraint, it's likely to evolve in this direction over the future,
> which is why I'm saying it's ideal if we align our visions.
> 
> > Also, when it is assigned to a team, the entire team is responsible for
> > bringing it to the next step, and contacting the team is as easy as
> > contacting a single person (thanks to launchpad :).
> 
> Not really. You can't, for instance, email the team (unless it has a
> contact email address, which is a bit of a corner case).

I don't want to discuss the corner cases where our workflow wouldn't
work for some other project/package because of lack of enforcement in
LP, since I can't control that :) It really has no bearing on the use
case (although I understand it does have bearing on the usability of LP
in general).

> > Having a list of bugs to work from is the loose sense of the reason it
> > is being used. The real use is to be able to separate responsibilities
> > within a single package.
> 
> Hmmm. What's the practical difference between the two things, apart from
> email notifications?

Listing of bugs to work from is important to the person who wants to
work on that bug-set. Showing responsibility (to either a team or a
person) is something other people are interested in...

> > I believe I've stated to the LP team once or twice in the past, that
> > being able to control the tags associated to a particular package would
> > make this easy to do without assigning to a team (would also make tags
> > much more useful), but something with more visibility would be best.
> 
> What do you mean by "more visibility"? I think we're getting somewhere,
> but not sure where yet! :-)

When other people go to a bug, they would like to know, instantly, where
responsibility for this bug lies. Is it the kernel team? Is it the
PowerPC port team? Is it the Alsa/Sound team? Who? In some points during
our workflow it is impossible to have a bug assigned to a person or no
one. The triaged state is one of those points.

Examples:

        #1 Bug says sound isn't working on Apple PowerBook G4. Bug is
        found to be legit, and is in the snd-aoa driver (powerpc
        specific). Mark it triaged.

        #2 Bug says sound isn't working on Apple PowerBook G4. Bug is
        found to be legit, and is in the snd-core driver (generic across
        all platforms). Mark it triaged.

Now at this point, following customary bug triaging, the bug should be
assigned to a person, but a triager can't know who that someone is. So,
leave it unassigned. Triager's can be trained to know which general team
it is for though. Let's face it, to triage kernel bugs, you need some
minimum training anyway.

Here's the problem. I (as a Canonical employee hired to work on the
kernel), care more about #2 than #1. I don't want to see #1. However,
someone on the powerpc-team cares about #1 for sure, and may care about
#2, but only in so much that it affects his architecture (the bug may
only show up in that particular hardware instance, but it is a general
bug none-the-less).

Further, if I am the submitter of that bug, or a subscriber to that bug,
how do I know who is ultimately going to fix it? Who is going to follow
up on the bug? Who should I contact when it gets ignored for some weeks?
With no assignee, there's no implied responsibility visible to the
submitter or interested parties.

With a triager assigning to "just someone", it will get the bug on
someone's list, and probably assigned to the right person somewhere down
the line, but creates a lot of noise for people on the team.

How best to represent this in Launchpad? Right now, it's being able to
assign to a team. I'll concede it isn't ideal, but it does solve the
problem.




More information about the Ubuntu-bugsquad mailing list