Sun, 22 Feb 2009
Ghost Bugs
Please consider the following hypothetical situation. gnome-screensaver keeps crashing for people on Jaunty, which is pretty annoying, so it sends lots of people to Launchpad to report a bug.
It's pretty quickly established by the amazing desktop team triagers that it's actually a problem in Gtk+, so they duly reassign the bug there.
However, it's a little while before the fix is forthcoming, and it that time many users are still getting hit by the bug, so they are still heading to launchpad. As most of us aren't Gtk+ hackers we don't see that the issue is there, so we go to the obvious place to report the bug, the gnome-screensaver package, and not seeing any existing reports about the bug we file a new one.
This means that the desktop team has to spend time shovelling the bugs over to Gtk+ and duplicating them to the first one. While we have some tools to help with this sort of thing it would be great if we could try and avoid it all together.
One way this could be solved in Launchpad is to leave a task open on the gnome-screensaver package, but this isn't ideal, as the bug doesn't need to be fixed there. You could mark a gnome-screensaver bug on the package as Invalid, which would make the dupe search as you report a bug show it, but it wouldn't show up for those that just trawled the open gnome-screensaver bug reports looking for the crash.
My idea for something that would help in this case is Ghost bugs. These are bugs that are the ghosts of a bug somewhere else. In the above case a ghost bug could be created against gnome-screensaver pointing to the Gtk+ bug. It would then show up in the bug lists, but not have a status etc., and be somewhat "greyed out", hence the name ghost bug.
As the bug affects gnome-screensaver it makes sense for it to show up against that, but as it doesn't need to be fixed there it shouldn't have the rest of the information.
It doesn't just work for packages. See for example launchpad bug #174539. This is a bug that should be fixed in bzr, but it only manifests itself in bzr-builddeb. I am keeping a task against bzr-builddeb so that it shows up in my list to fix to have bzr-buiddeb work great, but I don't really need a status as nothing needs to change in bzr-builddeb for it to work.
With Launchpad having the concept of bug tasks this could be easily done by adding a new status Ghost, or perhaps Fix Elsewhere or something. This would be handled differently to the other statuses, giving behaviour such as that I described above.
Having a whole bug task may not be the right thing though. It could instead be a separate list, similar to the list of bug tasks, but just listing the things that should have ghost tasks.
Does anyone else think this would be useful? Is there prior art?
A ghost bug would point out that the bug was moved to another project which causes the real bug, but it doesn't say anything about the status of the bug. It maybe be hard for people who want to track this bug (since they have issues with it and want to know when it is fixed). So a pointer to the bug filed in the other project might be of more use.
Also a ghost bug is easily made, but when would it be removed? Because there is no automatic reference to the real bug, this ghost bug would become a poltergeist, wandering around, and in the end somebody of the desktop team would need to head over to gtk+ to see if the ghost bug is still needed. Some automatic reference or cleaning process would also be a good idea in my opinion.
Posted by Sander Wiering at Sun Feb 22 14:48:07 2009
Posted by jldugger at Sun Feb 22 18:59:28 2009
The soft-link concept sounds very similar to the "Also Affects" tags, but perhaps not exactly the same. Perhaps a new field such as "Manifests itself in" field would correctly describe it.
Posted by Scott Wegner at Mon Feb 23 01:54:32 2009
Could probably be implemented by adding a new status for bugs "ALIAS OF".
We implement this in our local bugtracker by having a separate field that indicates in which sub-project the bug was originally logged, and the
bug shows up in that original sub-project even if it has been re-assigned.
Posted by Noel Grandin at Mon Feb 23 08:55:47 2009
I don't know Launchpad at all, but from my reading I am guessing that Launchpad will also track the status of the upstream bug, which is what is desired in this case.
Posted by Kai Grossjohann at Mon Feb 23 09:21:05 2009
Posted by Belinda at Mon Feb 23 13:48:35 2009
Posted by Belinda at Mon Feb 23 14:56:48 2009
Belinda, I think you missed the point of this post, it is not about the bug. If you have problems with your laptop please ask for help at https://answers.launchpad.net/ (you may need to register if you are a new user).
Posted by Sander Wiering at Mon Feb 23 22:31:21 2009
Posted by LaserJock at Tue Feb 24 18:17:01 2009
LaserJock, I think that should be done, and the situation could be improved a lot like that.
Another use I found for this was that I remembered there was a bug filed against policykit-gnome that I had found the fix for, but it had been re-assigned, and I couldn't remember where, and if it had left a ghost then I would have easily spotted it in the bug list for packagekit-gnome.
I think having the ghosts created whenever a bug is re-assigned might work quite well as a start.
The UI aspects of all of this would not be easy to get right though.
Perhaps a good way to start is just to leave a mark when a bug is reassigned, and then include those bugs when searching against the package.
Thanks,
James
Posted by James Westby at Tue Feb 24 19:10:52 2009