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

Bug #314432 reported by Graham Binns
158
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

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.

Graham Binns (gmb)
Changed in malone:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
William Grant (wgrant) wrote :

Is this not a duplicate of bug #216668?

Revision history for this message
Graham Binns (gmb) wrote : Re: [Bug 314432] Re: It's impossible to see all the bugs that affect a package if some bugs are targeted to one or more series and the Master task is closed

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

Yes, pretty much.

description: updated
Revision history for this message
Graham Binns (gmb) wrote : Re: It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed

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

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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

Revision history for this message
Brian Murray (brian-murray) wrote :

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

Changed in malone:
milestone: none → 2.2.2
Revision history for this message
Graham Binns (gmb) wrote :

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

Changed in malone:
importance: Medium → High
Revision history for this message
Björn Tillenius (bjornt) wrote :

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.

Changed in malone:
importance: High → Medium
milestone: 2.2.2 → none
Revision history for this message
Rick Spencer (rick-rickspencer3) 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?

Revision history for this message
Björn Tillenius (bjornt) wrote : Re: [Bug 314432] Re: It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed

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.

Revision history for this message
furicle (furicle) wrote : Re: It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed

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.

Revision history for this message
Graham Binns (gmb) wrote : Re: [Bug 314432] Re: It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed

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

Revision history for this message
furicle (furicle) wrote :

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

Revision history for this message
Graham Binns (gmb) wrote : Re: It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed

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

tags: added: platform-blocker
Changed in malone:
importance: Medium → High
Revision history for this message
Kees Cook (kees) wrote :

Any news on this?

tags: added: dhrb
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Any progress on this issue?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

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.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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?

Revision history for this message
Kate Stewart (kate.stewart) wrote :

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

tags: added: rls-mgr-p-tracking
Revision history for this message
Robert Collins (lifeless) wrote :

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.

Revision history for this message
Robert Collins (lifeless) wrote :

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

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

Escalated by Kate.

tags: added: escalated
removed: api
Revision history for this message
Francis J. Lacoste (flacoste) wrote :

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.

Changed in launchpad:
importance: High → Critical
Revision history for this message
Robert Collins (lifeless) wrote :

bug 423692 in particular has some good discussion

tags: added: seriesonlybugtasks
summary: - It's impossible to see all the bugs that affect a BugTarget if some bugs
- are targeted to one or more series and the Master task is closed
+ Series bug pages are missing bugs (and non-series bug searches hide bugs
+ still open in series / only assigned in a series)
Curtis Hovey (sinzui)
tags: added: milestones series
Curtis Hovey (sinzui)
tags: removed: escalated
Changed in launchpad:
importance: Critical → High
William Grant (wgrant)
tags: added: bug-search
Revision history for this message
Robie Basak (racb) wrote :

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?

Revision history for this message
Robie Basak (racb) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.