extra Status for upstream bugs in overview

[Brad Bollenbach]

On Wed, 2006-26-07 at 16:11 +1200, Matthew Paul Thomas wrote:
> -----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:

[snip]

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

Right. Let's say a bug affects three Ubuntu packages. According to what
Simon Law says, in practice there will usually be one main person in
charge of getting that bug fixed. Three statuses, three assignees, three
importances, three milestones, etc. is overkill in the common case.
(Remembering too that the number of bugs reported in more than one
package in a distro is measured in fractions of a percent.)

And we carry this complexity into every new design problem involving
bugtasks. Take release management: imagine how confusing it gets when
targeting this three-task bug to a release means adding /three more
tasks/! Why add three more tasks for that? Would it ever make sense to
add just two? What if the user rejects one of the targeted tasks? These
questions have to be answered at design time, because of how
fine-grained our current model is.

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

In practice, there is usually one main person in charge of fixing the
bug, even when more than one package is affected. For the fraction of a
percent of reported bugs where this is not the case, Malone's model will
breakdown. The other 99.9% of the time it will be much simpler to
understand and design for.

> >>> * 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. :-)

It might, but at least bugs and tickets would work so far.

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

Unfortunately, the benefits will often not be obvious until bugs start
being reported in many distros and upstreams.

Brad