Fwd: Massive bug expiration spree (Restoring all bugs to their previous status)

[Martin Pool]

---------- Forwarded message ----------
From: Curtis Hovey <curtis.hovey at canonical.com>
Date: Sep 25, 2007 11:29 AM
Subject: Re: Massive bug expiration spree (Restoring all bugs to their
previous status)
To: Launchpad-users <launchpad-users at lists.canonical.com>


We plan to restore all bugs marked as Invalid by the Launchpad Janitor
back to their previous status of Incomplete. We will also be removing
the message that the Launchpad Janitor left in the comments.

If you have already change the status to some of you bugs, they will not
be altered. We will leave them as you set them.

We are currently testing a script that will restore the bugs. We will
run it as soon as we are sure it is right.

We will are also preparing new documentation regarding the meaning of
the bug statuses.

We plan to revise the bug expiration process in two ways. Firstly, we
will warn users that incomplete bugs will be invalidated if action is
not taken (https://bugs.edge.launchpad.net/malone/+bug/141604). Secondly
we will revise the rules regard what qualifies a bug for expiration
(https://bugs.edge.launchpad.net/malone/+bug/141597).

We will perform a public test on staging with the revised expiration
rules. Launchpad users can see the results, and provide additional
feedback that we will incorporate into the rules. We will not run the
bug expiration process in production until the community agrees the
process is right.

I have posted an email to this thread regarding the 5 points that were
brought up on IRC and in the list. I'm repeating the list here since
this email has a title that stands out.

1. Duplicates are exempt.
   I agree with this rule. Duplicates that were wrongly Invalidated
   will be restored to Incomplete status.

2. bugs with milestones are exempt.
   I agree we should not be setting anything to Invalid if there is
   a milestone--but do we often agree to fix issues by a certain time
   that we have not confirmed to be a bug? The affected bugs can be
   restored to Incomplete in production, but that doesn't sound right.
   Were these bugs supposed to be confirmed?

3. Bugs with any valid upstream bugtasks are exempt.
   I cannot fathom the reason for this rule? Is this right? I'm sure
   I have seen bugs that are Confirmed on one package, and Invalid
   in another. I think this rule implies that when, for instance,
   HAL has a known bug, do not expire the Incomplete HAL x.x in
   Ubuntu package. But shouldn't the latter package be Confirmed in
   this situation? Would it be simpler, safer, and saner to have a
   rule to only expire bugs that affect a single location?

4. Use comment activity as the date indicator.
   This is doable of course, but we are trading the precision of
   location that may qualify for expiration for the general bug
   activity that may pertain to many locations. That is to say,
   When a bug affects many locations, the conversation may be about
   the true affected area, and the areas with Incomplete status
   are ignored. This may be the kind of insulation users want for
   Incomplete bugs.

5. bugs that have not had a reply are exempt.
   I agree with this. Is it common practice to set a bug to Incomplete
   Without asking the submitter for more information? I'm not certain
   every user of Launchpad understands the meaning of bug statues. If
   bugs are being set to Incomplete without a message, I wonder if we
   might want a definition of Incomplete in the email that goes out?



--
__Curtis C. Hovey_________
http://launchpad.net/

--
launchpad-users mailing list
launchpad-users at lists.canonical.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/launchpad-users




-- 
Martin
-------------- next part --------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBG+GSInGlTRlchMn0RAv1RAKDdMdLGet8mJd1Cd6wXOX8VKskesACg5UxW
vbINhUFtTYFkR3pr+JOPfts=
=8VuQ
-----END PGP SIGNATURE-----