Launchpad is losing my bugs

[Grondr]

I have several open bugs in Launchpad, some a couple of years (!) old, and most of them aren't showing up any more in any way I can find via searching, even though going directly to the relevant page by bug ID (if I know it!) works fine. For example, if I'm in the "Bugs related to Lenny Foner" page and try any of the Actions (list reported bugs, list commented bugs, etc), I get a very paltry list that misses many, such as https://bugs.launchpad.net/bugs/26266. Searching for "wake-on-lan" (mentioned in that bug report) also fails to find it. (I -know- it's missing others, but I'm going to have to grep my mail to find them all unless there's some magic search button I've failed to find---and if that's not the case, is Launchpad silently losing -lots- of bug in searches?)

[Sarah Kowalik (hobbsee-deactivatedaccount)]

it's marked as invalid - the default searches don't search for invalid, won't fix, or fix released bugs.

Are any of your bugs *not* in one of those states, yet not showing up on your page?

[William Grant (wgrant)]

That bug is closed (note the `Invalid'). It was changed to that almost 18 months ago.

[Grondr (grondr)]

Aargh! And, having closed the window in which I reported -this- problem, I couldn't even locate it again without finding it via the email I just got, since of course somebody invalidated this bug report and it failed to show up in my search. How enormously irritating! I mean, geez, invalid or not, the person who FILED it should be able to FIND it again, right? And commenters, etc? Making it vanish by default is pretty rude.

So is there any way to search for bugs that ARE marked invalid? Otherwise, I'm going to have to grep through my old mail to find other bug reports just to check them, and that's way more work than I'm willing to do.

Also: As far as I can tell, I never received any mail when this bug was invalidated (I just rechecked---I was absolutely subscribed to the bug, so shouldn't I have been informed upon the state change?), -and- I cannot find out WHO invalidated it, nor WHY (no comment to that effect---unless "rejected" by Ben Collins on 12 Jun 06 automatically marked it as "invalid", in which case it'd sure be nice if the terminology could be made consistent), -and- people are still commenting on it (most recently in August of this year to report that it's still broken in Edgy and Fiesty), -and- it's STILL broken in Gutsy (I just checked, and that's why I was trying to find this bug to comment on it). How did the people who commented on it recently manage to find it? And should one of them taken it upon themselves to change its state back to something that wasn't invalid? (They may not even have noticed---I sure didn't. That field is easy to miss if you're not looking for it, and it's in -gray-, which makes it just fade away on the screen...)

I'm currently trying to decide whether to reopen it (and maybe try to mark #160413 as a duplicate), or just leave it closed and file a brand-new bug, since this unfixed problem is now TWO YEARS OLD and the fact that it claims to be in linux-source-2.6.10 is probably misleading people into thinking that it's already fixed somehow in a later release. (And I have information on a workaround, which might lead to what's going wrong, but I'm not going to bother filing it for a bug that nobody's going to see, since the point is to get it fixed, not vanished down a black hole somewhere.)

Thanks...

[William Grant (wgrant)]

On Thu, 2007-11-08 at 05:29 +0000, Lenny Foner wrote:
> Aargh! And, having closed the window in which I reported -this-
> problem, I couldn't even locate it again without finding it via the
> email I just got, since of course somebody invalidated this bug report
> and it failed to show up in my search. How enormously irritating! I
> mean, geez, invalid or not, the person who FILED it should be able to
> FIND it again, right? And commenters, etc? Making it vanish by default
> is pretty rude.

Having default bug searches matching closed bugs simply would not scale.
Closed bugs are also likely uninteresting to most of the population.
There are trivial ways to locate such bugs, as detailed below.

> So is there any way to search for bugs that ARE marked invalid?
> Otherwise, I'm going to have to grep through my old mail to find other
> bug reports just to check them, and that's way more work than I'm
> willing to do.

Try an advanced search, the link to which should be next to the search
button above most or all bug listings. There you can select additional
statuses to display (by default, Invalid, Won't Fix and Fix Released
bugs are hidden - they are the closed statuses).

> Also: As far as I can tell, I never received any mail when this bug was
> invalidated (I just rechecked---I was absolutely subscribed to the bug,
> so shouldn't I have been informed upon the state change?), -and- I
> cannot find out WHO invalidated it, nor WHY (no comment to that effect
> ---unless "rejected" by Ben Collins on 12 Jun 06 automatically marked it
> as "invalid", in which case it'd sure be nice if the terminology could
> be made consistent), -and- people are still commenting on it (most
> recently in August of this year to report that it's still broken in Edgy
> and Fiesty), -and- it's STILL broken in Gutsy (I just checked, and
> that's why I was trying to find this bug to comment on it). How did the
> people who commented on it recently manage to find it? And should one
> of them taken it upon themselves to change its state back to something
> that wasn't invalid? (They may not even have noticed---I sure didn't.
> That field is easy to miss if you're not looking for it, and it's in
> -gray-, which makes it just fade away on the screen...)

The Rejected status was renamed to Invalid, and Needs Info to
Incomplete, some months ago. It was Ben's action that you referenced
which caused the transition to the Invalid status. People *should* take
it upon themselves to reopen it - anybody who is logged in can. Ben also
left a clear instruction 18 months ago: reassign it to the Dapper
kernel, linux-source-2.6.15, if you could confirm it still existed.

Anybody who has found it most probably did so through Google or an
advanced search.

> I'm currently trying to decide whether to reopen it (and maybe try to
> mark #160413 as a duplicate), or just leave it closed and file a brand-
> new bug, since this unfixed problem is now TWO YEARS OLD and the fact
> that it claims to be in linux-source-2.6.10 is probably misleading
> people into thinking that it's already fixed somehow in a later release.
> (And I have information on a workaround, which might lead to what's
>...

[Matthew Paul Thomas (mpt)]

Lenny, as described in bug 5977, the list of bugs you reported should show closed bugs by default, but it doesn't. Sorry for the confusion that bug has caused you.

[Grondr (grondr)]

Thanks, William and Matthew---this seems to indicate a -different- UI problem in Launchpad.

To wit: If I go to the advanced search (which I did, before I first filed this bug), and simply do a search with -none- of the "Status and importance" boxes checked, I -do- get -some- bugs. Exactly -which- of these checkboxes is checked "invisibly and by default" is not at all obvious; presumably it's documented somewhere, or one would have to try 'em all and use trial and error. (You've explained which ones are implicitly off in your comments, but that's not documentation, e.g., I shouldn't have to file a bug report to discover this... :) I -thought- (because many interfaces do this---though I think they're misleading when they do) that if NONE of the buttons were checked, they were implicitly ALL checked, but apparently not.

Now that I know this, checking -one- box ("Invalid"), I get many -more- bugs reported. So obviously this set of boxes is "any of several undocumented boxes in this list, UNLESS any boxes were actually checked by the user, in which case any of THOSE boxes, only." This is terrible design.

I suggest that the advanced-search page CHECK the boxes that ARE on by default*, so that way users can see what's really going on and that some of them AREN'T checked. If I'd seen that behavior from the start, I'd never have filed this bug, because my next action would have been to try checking the boxes that WEREN'T checked to see if more bugs surfaced.

[*Or, if it's deemed too inconvenient to have the user turn OFF a set of buttons before turning on some of the defaultly-unchecked ones, you could either have a "turn 'em all off" button you could hit first, or color them differently and have some sort of key -right beside them- explaining what's going on or something---I'd prefer the first of these options, because it's simpler and clearer.]

In the meantime, are people noticing that invalidated bugs are not sending mail about the change of state? Of course, for all I know, there was some bug along those lines months ago that was fixed since then, but I sure never got mail when this bug changed state.

[I'll go reassign the WoL bug to linux-source-2.6.22 once I've written up a workaround.]

Thanks.

[Matthew Paul Thomas (mpt)]

Lenny, you're correct that unchecking all the status checkboxes returns only open bug reports, and that this is weird behavior on Launchpad's part. That's bug 150867.