"Also needs fixing here" should make the same checks used in +distrotask.

Quoting Brad:

"I think the real fix here is that the "Also Needs Fixing Here" button..
shouldn't be shown at all; there's no point showing the button if..
clicking it /will/ raise an error. :) But I'll probably need some..
input from mpt."

I totally agree with Brad. Matthew what do you think?

How much sense does it make for a bug to be filed both on a distribution, and on one or more packages in that distribution? The early days of a vulnerability in commonly-statically-linked code might fall into this category, when not all of the buggy packages had been identified yet, so the bug needed attention from a general bugsquad. Is that something that ever happens? (Is zlib ever statically linked, for example?)

If they should be mutually exclusive, the first thing to do is fix Malone so that it crashes at step 2, not step 4. *Then* fix it so that the button isn't present in step 2. :-)

(This bug is sort of the opposite of bug 36286.)

Perhaps another example would be renaming a distribution or distribution release (e.g. Ubuntu 6.04 -> 6.06). A distribution manager reports a bug on the distribution saying "All references to X must be changed to Y", and that bug report is used to track the changes in all packages using the old name.

On Mon, 2006-22-05 at 04:39 +0000, Matthew Paul Thomas wrote:
> How much sense does it make for a bug to be filed both on a
> distribution, and on one or more packages in that distribution? The
> early days of a vulnerability in commonly-statically-linked code might
> fall into this category, when not all of the buggy packages had been
> identified yet, so the bug needed attention from a general bugsquad. Is
> that something that ever happens? (Is zlib ever statically linked, for
> example?)
>
> If they should be mutually exclusive, the first thing to do is fix
> Malone so that it crashes at step 2, not step 4. *Then* fix it so that
> the button isn't present in step 2. :-)

Based on the data I gathered from talking to Simon Law in Paris, it
makes sense to have only one task per distribution, distrorelease,
product, or productseries. Our current per-package assignee, milestone,
importance, etc. is too fine-grained 99.9% of the time.

Other things to consider:

* Mark wants the bug page to be contextless, which would mean this
button disappears completely.

* If we can show mark the value of context-as-a-magnifying-glass, and
decide to keep the bug page contextful, there are only two contexts
worth magnifying: distribution and product. Package-level context on the
bug page is confusingly fine-grained. This might make showing the button
an easier decision, showing it only if isn't marked as affecting the
current distro/product.

Brad

Fixed by fixing bug 246041.