bug janitor expires bug reports that should remain open.

Our policy is that duplicate bugs are invisible. They should not be modified.

Because of that, I just had about 10 emails from the janitor for all the numerous duplicates of one bug (the Firefox crashes because of Flash) that I am subscribed to.

Please note that the bug duped to this one had been marked critical. This one should be bumped.

The work to fix the expiration process is not critical because it is disabled--will not run until the community agrees that it is fixed. Critical means we are loosing data. High since this is a very important issue to the community.

The work to fix the corrupted data IS critical, and is not bound to the release cycle. I am waiting for a 'two-thumbs-up-thunderbirds-are-go-but-I-will-accept-a-simple-go to restore the bug statuses.

Well it was mpt that marked it critical, so take that up with him.

I marked it Critical before I knew that the automated expiry had been stopped. </metadiscussion>

(The original expiry report is Bug #91925 )

1. This bug is still present (see for example the Janitor's change to bug 131185)
2. The janitor appears to be runnig

See also bug 131348 and bug 75681.

The branch that fixes the expiration rules and adds the changes to the Activity log is in review.

Is there going to be an ability for projects to opt-out or have a different expiration window? The one size fits all timeline doesn't work everywhere.

On Mon, 2007-10-22 at 14:13 +0000, Scott Kitterman wrote:
> Is there going to be an ability for projects to opt-out or have a
> different expiration window? The one size fits all timeline doesn't
> work everywhere.

That is not planned. It has been discussed. It was felt that this
feature should be released as a general feature for all projects.
Project specific settings such as opting out, and configurable
expiration age should are a separate issue.

Then this 'feature' shouldn't be re-enabled until it is. So far (even
within the designed scope) I have seen nothing but increased workload to
reset bugs back to the desired state.

Fixed in RF 5131.

Tested OK against production data

On Tuesday 20 November 2007 12:07, Tom Berger wrote:
> Tested OK against production data

Is there public documentation that defines "OK"?

Not at this time. We are not planning to enable bug expiration until we release some additional features to view what can expire. The transliterated rules for expiration are

   1. The bug is not a duplicate.
   2. The bug has at least one message (a request for more information).
   3. The last update of the bug is older than 60 days.
   4. The bug does not have any valid tasks (only Incomplete, Invalid, or Wont Fix).
   5. The affected location has the status Incomplete.
   6. The affected location is a project that uses Launchpad to track bugs.
   7. The affected location is not assigned to anyone.
   8. The affected location does not have a milestone.

Fix released in Launchpad 1.1.11.

Where does one view what can expire?

Viewing what will expire is provided by two additional feature under development. Expiration will not be enabled until bug contacts have the tools to report and view bugs that can expire.
1. <https://bugs.edge.launchpad.net/malone/+bug/141604>: Expiration janitor should put an expiration notice on bug page.
2. <https://bugs.edge.launchpad.net/malone/+bug/163579>: Include a link on a project's Bugs page to a list of bugs that will expire.

So "Fix Released" is on the bug janitor process, it's not re-enabled yet?

That is correct. We will make the feature visible before it is actually turned on. Users will see what the process thinks it will do before we enable it. We want a comprehensive reintroduction of this feature; that is to say "no surprises."

Good. If we are going to have a feature like this (personally, I think losing failure data is a bad idea), then that's a much better way to do it than the first time.