Old bug reports
Carl Ansell
afccarl1994 at hotmail.com
Wed Aug 24 18:01:23 UTC 2011
Thanks for the replies.
I saw a bug report earlier that was marked as confirmed in Dapper, and fix released or invalid (can't remember which)in Edgy and there was a comment stating the issue was fixed in this release. The fix has not been backported, so what would be the best practice in this situation?
In realise that looking at old bugs might not seem like the most productive thing to do, but I have only just joined the bugsquad and feel that I am still learning about the whole bug reporting and triaging process. As such I think this would be a more simple thing to start with, given that many bugs have been inactive for years and would be less of an issue should I make a mistake.
Thanks again,
Carl
Date: Wed, 24 Aug 2011 09:37:21 +0100
Subject: Re: Old bug reports
From: timothy.mayoh at gmail.com
To: Ubuntu-bugsquad at lists.ubuntu.com
Sorry - I probably should have been more specific about marking bugs invalid immediately; I was referring to when the bug really didn't have anywhere enough information to work on it and no-one actually could reproduce it other than the reporter or whoever claims that it affects them, and only if they are all impossible to contact (as is already eventually done when there is no more activity on an incomplete bug for more than 60 days anyway).
If the bug is already confirmed or triaged and can be reproduced in newer, supported releases or the development release by other people, then I agree it makes no sense to ask the original reporter to test to see if it exists in a newer release just for the sake of it, if his/her version is still within support.
Although to this day I see many people reporting bugs with unsupported versions of Ubuntu who simply don't realise there is a newer version available or haven't upgraded for whatever reason who could do with a little push to switch to a current version, for their own benefit; for example I believe that to be the case with these bug reports: https://bugs.launchpad.net/ubuntu/+bug/827638 https://bugs.launchpad.net/ubuntu/+bug/827000
I'm not saying that upgrading will necessarily automatically fix the bug in every case, but it is always a good idea to be using a release which still receives security/performance/reliability fixes either way.
On 24 August 2011 03:50, Micah Gersten <micahg at ubuntu.com> wrote:
Corrected top posting...
On 08/23/2011 04:00 PM, Timothy Mayoh wrote:
On 23 August 2011 21:45, Carl Ansell <afccarl1994 at hotmail.com>
wrote:
There are many old reports in launchpad that apply to
unsupported versions of Ubuntu, such as Dapper and Edgy.
As these releases are no longer supported, can these be
marked as invalid?
I feel it would 'clean up' the bugs in launchpad and make
it clear which bugs are still relevant, but as someone new
to the bugsquad, I don't want to start messing with things
that I shouldn't mess with.
I believe the best approach would be to mark the report as
incomplete, and then try and contact the original submitter with
this canned response in the comments, assuming they are still
active: https://wiki.ubuntu.com/Bugs/Responses#Release_has_reached_EOL
. If they do not respond, then the bug would be automatically
marked as invalid within 60 days anyway.
This is only good if the bug isn't reproducible in the devel release
or in any release after it was reported (not saying they all have to
be tested, but that if a user chooses to test an older release and
can't reproduce, that should be sufficient). Otherwise, just asking
people to reproduce again was decided against in previous bugsquad
meetings as it annoys reporters and dissuades people from reporting
bugs.
Alternatively, if you are certain the original reporter and all
other people the bug affects are no longer active in Launchpad -
you can probably safely mark the bug as invalid immediately.
I don't agree with this. Just because the person is no longer
around doesn't make the bug invalid. Please remember, the point of
bug reports isn't to necessarily make people happy, but to find the
defects and actually repair them eventually.
Thanks,
Micah
--
Ubuntu-bugsquad mailing list
Ubuntu-bugsquad at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20110824/7c40599b/attachment.html>
More information about the Ubuntu-bugsquad
mailing list