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

[Graham Binns]

If you file a bug in a source package and then target it to a distro series (say Jaunty, which is the current Ubuntu development series) and also target it to Intrepid (an old series) and then close the Jaunty task (which is the master task in this scenario) the bug will disappear from the ubuntu/+source/$sourcepackage, even though the other task for the package is still open.

Since both of these tasks are on the same package (albeit different series and therefore different BugTargets) Launchpad should be smart enough to realise that the bug is still open on that package and show it in the general overview for that package, including series information as appropriate.

This also holds true for targeted BugTasks on Products and Distributions.

[William Grant (wgrant)]

Is this not a duplicate of bug #216668?

[Graham Binns (gmb)]

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

Yes, pretty much.

[Graham Binns (gmb)]

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

[Andreas Hasenack (ahasenack)]

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.

[Andreas Hasenack (ahasenack)]

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

[Brian Murray (brian-murray)]

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

[Graham Binns (gmb)]

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

[Björn Tillenius (bjornt)]

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.

[Rick Spencer (rick-rickspencer3)]

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?

[Björn Tillenius (bjornt)]

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.

[furicle (furicle)]

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.

[Graham Binns (gmb)]

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

[furicle (furicle)]

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

[Graham Binns (gmb)]

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

[Kees Cook (kees)]

Any news on this?

[Marc Deslauriers (mdeslaur)]

Any progress on this issue?

[Jamie Strandboge (jdstrand)]

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

[Francis J. Lacoste (flacoste)]

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.

[Jamie Strandboge (jdstrand)]

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?

[Kate Stewart (kate.stewart)]

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

[Robert Collins (lifeless)]

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.

[Robert Collins (lifeless)]

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

[Francis J. Lacoste (flacoste)]

Escalated by Kate.

[Francis J. Lacoste (flacoste)]

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.

[Robert Collins (lifeless)]

bug 423692 in particular has some good discussion

[Robie Basak (racb)]

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?

[Robie Basak (racb)]

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