extra Status for upstream bugs in overview

[Brad Bollenbach]

On Tue, 2006-25-07 at 16:36 +1200, Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Jul 25, 2006, at 1:32 AM, Brad Bollenbach wrote:
> > ...
> > 2. To minimize confusion, a bug listing should not list the same bug
> > more than once, regardless of where the bug's reported.
> 
> <https://launchpad.net/bugs/1357>
> 
> > I don't have a good solution for this problem yet, but here are some
> > brainstorm ideas to help consider different aspects of the problem in
> > more detail:
> >
> > * Allow a bug to have only one status per
> > distribution/distrorelease/product, rather than being able to track 
> > the assignee, status, milestone, importance, etc. per bug per package. 
> > This makes it easy to not duplicate a bug in a distro or product bug 
> > listing and reduces the likelihood of seeing dupes in +subscribedbugs 
> > and such, and would generally simplify tracking the status of a bug.
> 
> Sometimes the same bug will need fixing in multiple packages.

I'm suggesting that if, say, three packages are affected in a distro,
that would be one task with three packages associated to it, rather than
three tasks, each having their own assignee, status, importance,
milestone, etc.

Our current, per-package model, is unnecessarily complicated, as Simon
Law brought to my attention in Paris.

> > * Allow a user to associate themselves with distributions and products
> > in a user preferences screen. This information could act a magnifying 
> > glass on bug listings, and bug pages, and other parts of Launchpad. 
> > So, if you're associated with distro A, but not distro B, and a bug is 
> > reported in both, you see only the status for distro A in your 
> > +subscribedbugs list. Some exceptions would be made, like being shown 
> > that a "fix exists" if the bug was fixed upstream or by another 
> > distro.
> 
> I think that would be unnecessarily difficult to understand and 
> configure, as well as not working for people who weren't logged in.

I think it can be made not too difficult to understand. For example
(disclaimer: high-level, brainstorm idea) after filing a bug on Ubuntu,
we could suggest to the user "Do you want to _add Ubuntu to your watch
list_? (_huh?_)"

It should work fine for people who are not logged in, because the
"contextless" reports which are the hard ones to address for repeating a
bug--+subscribedbugs, +reportedbugs, +assignedbugs, +packagebugs--aren't
accessible to anonymous users.

And the app isn't "broken" if Malone doesn't know what software you care
about most; it'll just be less effective in presenting you the
information most interesting to you.

> > * (The most obvious one) Collapse all statuses of a bug into a single
> > row. mpt would need to be consulted for how best to do this.
> > ...
> 
> Something like "Confirmed in Ubuntu, Fixed in 2 others" would work if 
> the search results weren't a table. I'll need to think more about how 
> to show it in the table.

If I'm interested (i.e. I'm a developer, active bug reporter, blogger
evangelist, etc.) only in one of the distros where it's already Fixed,
do I care to see that it's "Confirmed in Ubuntu"? (This is why I'm
suggesting something like a watch list.)

Brad