Hi all. I’ve started trying to collect some historical data about various packages’ bug backlogs (since I don’t know how to query it arbitrarily from Launchpad). And there seems to be a couple of outliers at the moment. Both Nautilus and Xorg in particular need some TLC.
Xorg also needs a little attention (https://bugs.launchpad.net/ubuntu/+source/xorg). However I think many users like to log bugs there that are actually nothing to do with xorg. Xorg server bugs should be moved to xorg-server, and newer Gnome Shell bugs should be moved to source package gnome-shell or mutter.
I’ve just killed half-a-dozen nautilus bugs with a generic “can you check on a newer release” message. I’ll try to squash some more through the evening.
Thanks @lucyllewy. Don’t be afraid to set old bugs straight to Invalid, if not Incomplete. So long as it’s accompanied by a reasonable message nobody should be shocked by that:
I’m using “incomplete” so that the original reporter has a chance to re-check the current state of the bug if they feel inclined. IIRC bugs set to incomplete will auto close after a period (90 days?) so even though I’m not closing them directly they’ll be more likely to fall out of scope in time rather than sitting open.
Thanks, this is the right thing to do as, as you said, some issues on a EOL release may still exist on a supported or the development release.
They will be set to “Expired” after 60 days if it has the “Incomplete” status and:
I do both:
I usually do a quick over the bug and if try to determine if it looks like it will be relevant for the dev release (try to reproduce, see if that feature was dropped, etc). If it seems likely not relevant I say why I think so and mark it Invalid.
If there is a significant chance it could affect a new release, then I do Incomplete.
Sounds like general housekeeping.
Based on some things I’ve seen lately it seems you all are also in need of more bug triager’s & people who can clean crashers & move them from private to public for a bit more exposure.
An example is https://bugs.launchpad.net/bugs/1737701 which has been private for probably 4 months & something that will greatly affect some users in 18.04 if not dealt with
(- the actual bug is on libcdio17 which has a public untriaged bug with simple fix.
Instructions like these should enable people to do that themselves, but yes, sometimes someone else may need to do it to get the bug moving… admittedly I haven’t sorted out my own private bugs
it contains no bug watches or links to external bug trackers.
So if there is a bug watch pointing at an external tracker then the bug will never auto-close. You should check the links to external trackers and decide if they are still useful. If not then you will need to delete the links before the automatic 60 day countdown can start. You will occasionally find Incomplete bugs that should have expired already but did not, because of this.
Search errors.ubuntu.com (sorry if you don’t have access, I don’t remember the procedure). Find other instances of the crash and group them all together into a single bug report.
Get a .crash file from the user, or else the bug should remain Invalid. You may need to start by asking them to “apply the workaround from bug 994921”. Then they should be able to look in /var/crash, find the relevant file and upload it to a new bug using ubuntu-bug /var/crash/WHATEVER.crash. But attaching crash files to existing bugs is not helpful.
Once you have a retraced bug report from the user via ubuntu-bug you can mark the first bug as a duplicate of the second one.
If still in doubt, keep the bug Incomplete until a satisfactory amount of system logs and other information is attached.
For this type of bug where there is no duplicate, heat is low, it affects only one user and has been reported against an old release, you can safely use the standard “Old Untouched” response from the Bug Squad’s Knowledge Base, set it to incomplete and let it expire.
For this very specific bug you pointed out, I’ll just close it since I’m the reporter, it never happened again and affects no one else.