extra Status for upstream bugs in overview

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 26, 2006, at 1:42 AM, Brad Bollenbach wrote:

> On Tue, 2006-25-07 at 16:36 +1200, Matthew Paul Thomas wrote:
> ...
>> On Jul 25, 2006, at 1:32 AM, Brad Bollenbach wrote:
> ...
>>> * 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.

I don't think I understand that. Having a single status per task is 
unnecessarily complicated, but having multiple packages per task would 
be simpler? How does that work?

If a bug needs fixing in multiple packages, it won't necessarily even 
be fixed by the same person in each, let alone in the same day.

>>> * 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?_)"

I think that would be taunting people, by making them think that the 
(much more useful) product/package/distribution subscriptions had been 
implemented, when they haven't. :-)

I was a bit unclear, in that by "unnecessarily difficult to understand 
and configure" I was referring to the ratio of effort to benefit. I 
don't think people will be bothered maintaining such a list of 
distributions/products they're interested for such a minor benefit.

> 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.
> ...

Good point.

- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFExutu6PUxNfU6ecoRAtSuAJ4soR56c3BDauYaoOSX54jFjAPX3ACeMlNl
x0j59moe+h9GO4d5XvB5Nn4=
=X4zP
-----END PGP SIGNATURE-----