Series bug pages are missing bugs (and non-series bug searches hide bugs still open in series / only assigned in a series)

Is this not a duplicate of bug #216668?

2009/1/10 William Grant:
> Is this not a duplicate of bug #216668?

Yes, pretty much.

I'm marking bug 216668 as a dupe of this one since this bug has the more verbose description.

I find this bug dangerous, as it can make critical bugs just disappear from your radar if they affect more than one project and the fix is marked resolved in the other project. Just happened with #317241, for example, as it now disappeared from all Landscape bug reports in Launchpad. Somebody not working with Landscape bugs every day would not be aware of this problem and not notice this disappearance.

I'm sorry, what I wrote above specifically about #317241 is incorrect. It's NOT an example for this bug.

I believe bug 290125 might also be a duplicate of this one.

Re-triaging this as High since it one of the dupes was high; this affects Ubuntu QA.

This bug may be important to fix for some people, but it's very hard to fix this. I doubt we'll have the bandwidth to resolve this issue before 3.0.

Does the fact that it is hard to fix really impact the importance? This bug causes a lot of extra work for Ubuntu, and may well impact the quality of it. I understand that it may be hard to fix quickly, but why would that change the importance?

On Fri, Feb 20, 2009 at 02:43:17PM -0000, Rick Spencer wrote:
> Does the fact that it is hard to fix really impact the importance? This
> bug causes a lot of extra work for Ubuntu, and may well impact the
> quality of it. I understand that it may be hard to fix quickly, but why
> would that change the importance?

Yes it does. If something is easy to fix, it's usually not a problem
fixing it right away, because it won't affect other work. If it's hard
to fix, it means that we have to postpone something else. The importance
is an incidator of when we should fix it. The higher it is, the sooner
we should fix it. If we don't have time to fix something, it's wrong to
have it as High importance. You can't have too many top priorities at
once. (And yes, we have been using High importance too much in the past,
so we have way too many High bugs already, which should probably be
lowered.)

Let's see if we can arrange for a meeting with some of the affected
people, though. I'd like to know a bit more about the real issue, maybe
there is some change in workflow that can be done, or even a small fix
in Launchpad.

I don't think your comments about priority vs time to fix is at all appropriate.

If you don't have time to fix it, fine, but that doesn't change the fact it should have been fixed! Don't revise history to make things look good. Too many high priority fixes not being done indicates a problem that needs to be resolved in itself. Masking it by down playing important bugs is not appropriate.

2009/2/25 furicle:
> If you don't have time to fix it, fine, but that doesn't change the fact
> it should have been fixed!  Don't revise history to make things look
> good.   Too many high priority fixes not being done indicates a problem
> that needs to be resolved in itself.  Masking it by down playing
> important bugs is not appropriate.

Except that the bug history
(https://bugs.edge.launchpad.net/malone/+bug/314432/+activity) shows
that the importance has been changed, so any accusations of
revisionism are spurious at best.

That we have so many High importance bugs that we haven't had chance
to fix is a sign of two things:

1. We don't have enough developers to tackle them all
and
2. We've been prioritising too many things as High.

In this case I bumped the bug up to High because that was the
importance of one of its duplicates. In hindsight, though, I agree
with Bjorn, it should have stayed as Medium, where Medium means 'it
would be nice to fix this in [whatever milestone it gets targeted to]
but if it slips the cycle it's not the end of the world.' High, by
contrast, means "It's important that this is fixed in $cycle; there
should be no reason for it to slip."

On Wed, Feb 25, 2009 at 5:03 PM, Graham Binns <email address hidden> wrote:
> In hindsight, though, I agree
> with Bjorn, it should have stayed as Medium, where Medium means 'it
> would be nice to fix this in [whatever milestone it gets targeted to]
> but if it slips the cycle it's not the end of the world.' High, by
> contrast, means "It's important that this is fixed in $cycle; there
> should be no reason for it to slip."

Is this formally defined somewhere? Just curious if everyone is on
the same page.

And if this falls into your case 2 by all means drop it down. I don't
have an opinion worth counting on that.
> 2. We've been prioritising too many things as High.

I was just saying I don't think lack of man power is justification for
changing the priority, just justification for not getting it done.
I'll go be quiet now :-)

Marked as a platform blocker, carried over from bugs 322009 and 495647, in accordance with Kees' comment:

"I've upgraded this to "platform-blocker" since it gets in the way of Security Queue Sponsorship, now that we've merged security processes with the general Ubuntu Sponsorship processes: https://wiki.ubuntu.com/SponsorshipProcess"

I'm marking this as high, too, in light of this tag and the fact that bug status in Launchpad is no longer so tightly linked with likelyhood of scheduling (this has changed since open-sourcing, for the record).

Any news on this?

Any progress on this issue?

While this is a pretty ancient bug, it is still a significant problem for the security team. Is there any progress on this bug?

There is no progress on that bug. I suggest you talk to Bryce or Kate to see how it fits among the other bugs Ubuntu and Platform want fixed. They can escalate it and it will raise the priority to Critical which will put it on the maintenance squads plate.

Talking with skaet about this now. As manager of the security team, I wonder why I cannot escalate this to Critical myself. Are there guidelines posted somewhere so I can follow them?

Francis, what is the effort necessary to get this fix incorporated?

We'll want to escalate from the ubuntu engineering side, since it affects the security team, QA, release and stable release teams.

Thanks, Kate

The bug will still be open on the *series*, its because we have two different contexts at play:
 - the distro
 - and the series

Searches on the distro currently *only* return bugs on the distro, searches on the series currently *only* return bugs on the series.

Changing this is possibly best done as part of the only-series-bugs proposal, which would remove the distro itself as a context for bugs and make all tasks be for one of the distro series.

Anyhow, to work around, search both the series and the distro.

(For implementors: beware query performance if you consider just oring the contexts/unioning in the series. Bug searches are already fragile performance wise.)

Escalated by Kate.

Jamie: we accept escalation requests from a designated person in each department. The idea is that person has a view of all the requests coming in from their department and his able to do a first pass at prioritization.

bug 423692 in particular has some good discussion

This also affects distribution.searchTasks() in the API. Could the current behaviour of distribution.searchTasks() please be documented - that you need to work around by iterating and unioning over a searchTasks() call for each series? Do you want a separate bug for the API side and/or the API documentation side?

> that you need to work around by iterating and unioning over a searchTasks() call for each series

FTR, this additionally needs to be unioned with the ("top level") distribution.searchTasks(); otherwise bugs with no specific series tasks get missed.