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/
Attachment:
signature.asc
Description: This is a digitally signed message part
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)