A couple of changes to note

[Greg Grossmeier]

There was a decision made to not actually mark "expired" bugs as
invalid as, I believe, there was some vocal opposition to it.  So
Ubuntu has been one of the projects to "[disable] bug expiry are part
of the bug expiration process."

This page [0] will list all bugs that are 'expirable' and is linked to
from the main Ubuntu bugs page on Launchpad.

Best,

Greg

[0] https://bugs.edge.launchpad.net/ubuntu/+expirable-bugs

On Wed, Mar 4, 2009 at 1:56 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
> Hi,
>
> Can you explain how this policy fits/integrates with the
> https://help.launchpad.net/BugExpiry automated process which "expires" bug
> reports after 60 days when some conditions are met?
>
> ==========================================================
> Launchpad will mark bugs as candidates for expiry if it appears that they
> have been abandoned. To determine if a bug has been abandoned, Launchpad
> uses the following conditions:
>
> it has the "Incomplete" status
> the last update was more than 60 days ago
> it is not marked as a duplicate of another bug (duplicate bugs have no
> status of their own and so aren't expirable).
> it has not been assigned to anyone
> it is not targeted to a milestone.
>
> Only projects and distributions that use Launchpad as their bug tracker and
> that have not disabled bug expiry are part of the bug expiration process.
> ============================================================
>
> For example, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/85796
> was marked for expiry yesterday, however there is no observable change to
> the bug report I can detect. How does one list "expired" bug reports?
>
> Thanks
>
> On Wed, 2009-03-04 at 06:53 -0500, Mackenzie Morgan wrote:
>
> On Wednesday 04 March 2009 5:26:35 am Wolfger wrote:
>> Speaking as somebody who does a lot of invalidating of old bugs, I
>> have to say that responses from the submitter are the exception, not
>> the rule. Maybe (and I'm being generous) 10% of these bugs see life
>> again. So this (proposed?) change only adds to the work load without
>> providing any extra value. Under the 4-weeks-to-dead system, a triager
>> only touches the bug once, and if the bug is still alive, the
>> submitter touches the bug once. Under this new system, triagers will
>> have to touch the bug twice if they are dead (don't play with dead
>> bugs!), but the process for it's-not-dead-yet bugs hasn't actually
>> changed at all.
>
> Leaving a bug which has not had a response alone, in incomplete-without-
> response mode does not hurt anything.  They don't *need* to be closed.
> Prompting the user to supply more of the needed input can be good.  Going
> through the list of bugs last touched 28 days ago and killing them makes
> reporters feel ignored. The bugs aren't dead til you invalidate them.
> Someone
> that can reproduce it can supply the needed input.  Once you invalidate, it
> goes off everyone's radar and stops showing up in bug searches, so people
> who
> can reproduce have to go through submitting a whole new bug when they
> could've
> just added the one missing piece of information to the original.
>
> Triaging's not about closing as many bugs as possible.  It's about improving
> bug reports.  You could say "resolving" bugs, but "nevermind we don't want
> to
> deal with you because you're not prompt enough" isn't really a resolution.
>
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>