Enable bugs expiration for Ubuntu

[Francis J. Lacoste]

A lot of bugs are marked for expiration and some of them should have been expired.

Unfortunately, the script handling expiration has never been put back in service.

We should either enable expiration or remove that feature.

[Eleanor Berger (intellectronica)]

I think that this is a very important feature, and would really like to see it enabled again.

Before we proceed, though, we have to make sure that all the problems that were raised when the feature was first experimented with, are addressed.

Do we have such a list anywhere? And if not, could you, ~sinzui, help preparing it? (I think you were dealing with this feature at the time)

[Graham Binns (gmb)]

One of the things we discussed at the Bugs team sprint last July was
adding an "Expired" status. This removes one of the problems we had
with expiration, which was that we marked expired bugs "Invalid" with
all the connotations that that has.

I think it would be worth adding this status (and make it settable
only by the Janitor) before we turn expiration back on.

[Eleanor Berger (intellectronica)]

2009/2/23 Graham Binns <email address hidden>:
> One of the things we discussed at the Bugs team sprint last July was
> adding an "Expired" status. This removes one of the problems we had
> with expiration, which was that we marked expired bugs "Invalid" with
> all the connotations that that has.
>
> I think it would be worth adding this status (and make it settable
> only by the Janitor) before we turn expiration back on.

+1

I think that this will alleviate a lot of the pain users felt with
this process in the past.

[Curtis Hovey (sinzui)]

I think the expire-bugtasks.py script is ready to use. We need to announce our intent to the user and invite them to set their projects up to allow expiration. We run the script of staging to let users see what will happens. 18 months have passed since the failed release, and I'm sure projects are not using bug statues as we defined them. The first run is brutal because of the large backlog.

I'm indifferent to introducing a new status.

[Graham Binns (gmb)]

> I think the expire-bugtasks.py script is ready to use. We need to
> announce our intent to the user and invite them to set their projects up
> to allow expiration. We run the script of staging to let users see what
> will happens. 18 months have passed since the failed release, and I'm
> sure projects are not using bug statues as we defined them. The first
> run is brutal because of the large backlog.

Is it worth us running for a cycle or two with a notice to maintainers
on the project front page to let them know we're going to turn
expiration back on? Something like:

(i) Launchpad will soon start expiring bugs that have been incomplete
for more than sixty days for projects that choose to expire incomplete
bugs. $project is[n't] configured to expire bugs. You can change this
setting on the [link to $project/+edit page].

Before - well before - we turn expiration back on, I think it's worth
us making announcements in all the right places - blog, lp-users,
maybe some of the Ubuntu lists - making it clear what we're doing,
when and why and how people can opt in or out as they wish.

[Eleanor Berger (intellectronica)]

2009/2/23 Graham Binns <email address hidden>:
>> I think the expire-bugtasks.py script is ready to use. We need to
>> announce our intent to the user and invite them to set their projects up
>> to allow expiration. We run the script of staging to let users see what
>> will happens. 18 months have passed since the failed release, and I'm
>> sure projects are not using bug statues as we defined them. The first
>> run is brutal because of the large backlog.
>
> Is it worth us running for a cycle or two with a notice to maintainers
> on the project front page to let them know we're going to turn
> expiration back on? Something like:
>
> (i) Launchpad will soon start expiring bugs that have been incomplete
> for more than sixty days for projects that choose to expire incomplete
> bugs. $project is[n't] configured to expire bugs. You can change this
> setting on the [link to $project/+edit page].
>
> Before - well before - we turn expiration back on, I think it's worth
> us making announcements in all the right places - blog, lp-users,
> maybe some of the Ubuntu lists - making it clear what we're doing,
> when and why and how people can opt in or out as they wish.

I think an email to maintainers (possibly even with the list of bugs
that are currently candidates for expiration) would be a good way to
get their attention. I don't like the idea of displaying a notice in
the web UI for very long.

[Graham Binns (gmb)]

> I think an email to maintainers (possibly even with the list of bugs
> that are currently candidates for expiration) would be a good way to
> get their attention. I don't like the idea of displaying a notice in
> the web UI for very long.
>

Email's a much better idea. Let's do more of that.

[Eleanor Berger (intellectronica)]

2009/2/23 Graham Binns <email address hidden>:
>> I think an email to maintainers (possibly even with the list of bugs
>> that are currently candidates for expiration) would be a good way to
>> get their attention. I don't like the idea of displaying a notice in
>> the web UI for very long.
>>
>
> Email's a much better idea. Let's do more of that.

Sorry, I should have explained that the reason of a notice on the
website is that it can't be dismissed by users after they've read it.
It is likely to become a minor irritant to people after a while. An
email is in the user's control, and if it contains a list of bugs it
can be used as a to-do list for later use.

[Graham Binns (gmb)]

> Sorry, I should have explained that the reason of a notice on the
> website is that it can't be dismissed by users after they've read it.
> It is likely to become a minor irritant to people after a while. An
> email is in the user's control, and if it contains a list of bugs it
> can be used as a to-do list for later use.

No need to explain - I got it. I'd actually forgotten that we could
get a list of the relevant maintainers and contact them by email - oh
the power of, yanno, owning the database.

[Martin Pitt (pitti)]

This was discussed again at the last UDS for Lucid. The general opinion was that we get so much bug flood nowadays for Ubuntu that it's high time to automatically expire bugs which have no assignee and are "incomplete without response" for more than a month (or so; two months are certainly fine as well).

Deryck Hodge agreed to working on this in https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management, so I convert that whiteboard work item into a reference to this bug.

[Martin Pitt (pitti)]

Quoting from blueprint: This would work better with a new "Expired" state (which can't be set from the web UI), but "Invalid" will do for now.

[Deryck Hodge (deryck)]

Yes, an "Expired" status should be added for this. It should not be settable from the UI, only by the script that expires bugs.

[Deryck Hodge (deryck)]

Note, too, that I'll leave this assigned to me so we don't lose it, but any bugs hacker can take it unless I've put it "In Progress" by me.

[Curtis Hovey (sinzui)]

I really want this enabled for projects too. I have setup projects to use it, but I must manually invalidate bugs each release because they are 60 days old.

I do not think there is any work to do. The feature is implemented, someone needs the courage to enable it.

[Martin Pitt (pitti)]

> I do not think there is any work to do. The feature is implemented,
> someone needs the courage to enable it.

Is that something that can be enabled per-project/distro in the project details, or is it a global on/off thing?

[Graham Binns (gmb)]

2010/1/20 Martin Pitt <email address hidden>:
>> I do not think there is any work to do. The feature is implemented,
>> someone needs the courage to enable it.
>
> Is that something that can be enabled per-project/distro in the project
> details, or is it a global on/off thing?
>

IIRC it's global, in that we have to enable the janitor.

[Curtis Hovey (sinzui)]

The feature is global, but each project/distro must enabled it from the Change details (+edit) page.

[Martin Pool (mbp)]

On 19 April 2010 19:52, Abel Deuring <email address hidden> wrote:
> ** Changed in: malone
>       Status: Triaged => Fix Committed

Yaybut. Please please make sure this is prominently advertised before
it fires, so we don't have a repeat of the previous schmozzle.

What I might suggest is:

* turn off the flag for all projects
* advertise that the feature is available again, and that people can
turn it on if they want it

If you actually want this to happen, clicking the control again is not
an unreasonable burden.

--
Martin <http://launchpad.net/~mbp/>

[Deryck Hodge (deryck)]

We are planning a blog post and a launchpad users list mail with 2-3 days warning before turning on the script again. This bug being Fix Committed really just means the EXPIRED status has been added to the code.

I had not considered disabling this for all projects. Thinking about it now, I'm not sure we should do that. If we didn't set this by default when the feature was originally launched, then I don't think we would want to disable it automatically now. Presumably, people who enabled this feature wanted it.

[Ursula Junque (ursinha)]

Fixed in stable r10735 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10735>

[Martin Pool (mbp)]

On 19 April 2010 20:48, Deryck Hodge <email address hidden> wrote:
> We are planning a blog post and a launchpad users list mail with 2-3
> days warning before turning on the script again.  This bug being Fix
> Committed really just means the EXPIRED status has been added to the
> code.
>
> I had not considered disabling this for all projects.  Thinking about it
> now, I'm not sure we should do that.  If we didn't set this by default
> when the feature was originally launched, then I don't think we would
> want to disable it automatically now.  Presumably, people who enabled
> this feature wanted it.

Or were wondering what it did, or it was set by somebody years ago
who's now left the project.

I suspect most users don't regularly read the blog or the mailing list.

What's the worst that could happen? If you leave them turned on,
massive email spam and complaints. If you turn them off and then let
people turn them back on, the worst is a few people needing to find
from this bug that they need to turn it back on.

--
Martin <http://launchpad.net/~mbp/>

[Curtis Hovey (sinzui)]

On Tue, 2010-04-20 at 00:17 +0000, Martin Pool wrote:
> On 19 April 2010 20:48, Deryck Hodge <email address hidden> wrote:
> > We are planning a blog post and a launchpad users list mail with 2-3
> > days warning before turning on the script again. This bug being Fix
> > Committed really just means the EXPIRED status has been added to the
> > code.
> >
> > I had not considered disabling this for all projects. Thinking about it
> > now, I'm not sure we should do that. If we didn't set this by default
> > when the feature was originally launched, then I don't think we would
> > want to disable it automatically now. Presumably, people who enabled
> > this feature wanted it.

We have been promoting this feature in the UI for two years. We also
have users wondering why expirable bugs do not expire. Though the UI
counts down from 60 days based on bug history, it will in fact continue
to count after the expiration mark is reached:
https://bugs.edge.launchpad.net/malone/+bug/127348

> Or were wondering what it did, or it was set by somebody years ago
> who's now left the project.

I expire bugs every month by hand. There are no complaints. Most of the
bugs I have expired I inherited from other Lp projects. There are
discussions about follow up, and I have reopened a few bugs *after* the
user could help explain how to reproduce this problem.

> I suspect most users don't regularly read the blog or the mailing list.

I expect users to read their own bugs.

> What's the worst that could happen? If you leave them turned on,
> massive email spam and complaints. If you turn them off and then let
> people turn them back on, the worst is a few people needing to find
> from this bug that they need to turn it back on.

The email makes it clear which needs to be updated

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

[Martin Pool (mbp)]

Please think this through very seriously before letting it go into
production. Perhaps it needs to go through some kind of review
process. If there is any kind of red button for UI review, consider
it pushed.

When this feature was originally turned on ~2 years ago, it caused a
great amount of bug spam and much consternation to users. The
Launchpad team ended up issuing a public apology
<http://<email address hidden>/msg02379.html>.
 I don't want to see that repeated.

On 20 April 2010 12:10, Curtis Hovey <email address hidden> wrote:
> On Tue, 2010-04-20 at 00:17 +0000, Martin Pool wrote:
>> On 19 April 2010 20:48, Deryck Hodge <email address hidden> wrote:
>> > I had not considered disabling this for all projects.  Thinking about it
>> > now, I'm not sure we should do that.  If we didn't set this by default
>> > when the feature was originally launched, then I don't think we would
>> > want to disable it automatically now.  Presumably, people who enabled
>> > this feature wanted it.
>
> We have been promoting this feature in the UI for two years. We also
> have users wondering why expirable bugs do not expire. Though the UI
> counts down from 60 days based on bug history, it will in fact continue
> to count after the expiration mark is reached:
> https://bugs.edge.launchpad.net/malone/+bug/127348

Yes, I know all this. I've wondered myself why things were not
working in the way the UI says they would, and iirc I updated the help
wiki myself to explain that it was disabled.

I'm glad you're reenabling the feature, I just want you to reenable it
in a way that will please rather than annoy users.

It's bad to have a UI control present for 2+ years that does nothing.
It's worse to make it suddenly turn back on and abruptly catch up on
past data.

>> Or were wondering what it did, or it was set by somebody years ago
>> who's now left the project.
>
> I expire bugs every month by hand. There are no complaints. Most of the
> bugs I have expired I inherited from other Lp projects. There are
> discussions about follow up, and I have reopened a few bugs *after* the
> user could help explain how to reproduce this problem.

I presume you mean you manually expire Malone bugs. That's fine. I
would be very unhappy if you suddenly decided you were going to expire
all the bzr bugs that you thought were inactive. I expect the
unhappiness will come from Launchpad-using developers, not from the
users whose bugs are closed.

>> I suspect most users don't regularly read the blog or the mailing
> list.
>
> I expect users to read their own bugs.

If they read the bugs they'll find about the expiry after everything
has been done. I don't think doing bulk changes with no prior warning
is very nice.

>> What's the worst that could happen?  If you leave them turned on,
>> massive email spam and complaints.  If you turn them off and then let
>> people turn them back on, the worst is a few people needing to find
>> from this bug that they need to turn it back on.
>
> The email makes it clear which needs to be updated

People won't see the email until all their old bugs have been expired.

Though this does suggest an alterna...

[Martin Pool (mbp)]

That last bit is of course just what Tom said in #6 a year ago.

[Deryck Hodge (deryck)]

I think an email to bug supervisors is a fine precaution. We did, of course, discuss this option and like Curtis we felt all the UI warnings in Launchpad were enough to make people connect the dots on this as long as we did a blog post and email. We do understand not everyone reads the blog or launchpad users list, but these are our main channels of communication so we have to use what we have available. However, given the sensitivity or potential sensitivity of this coming change, we can err on the side of caution and send emails to bug supervisors. I can also post to the ubuntu-devel mailing list, which will hit a wider audience.

Does this make you more comfortable with re-enabling this, mbp?

Note, too, that we're not rushing this change through. Abel is doing thorough QA on it to make sure the status works as expected and to make sure the issues mentioned under "what wen wrong" in the email you cite above are indeed fixed. Our goal is to make sure this works as we say it does and then advertise the coming change as much as we can before we actually enable the bug expiring script.

Cheers,
deryck

[Brian Murray (brian-murray)]

I'm rather interested in this and seeing it enabled and working well. Subsequently, I wrote some launchpadlib code to double check expirable Ubuntu bug tasks and ensure that bugs really should expire. Incidentally, its rather unfortunate that there is no way to search for expirable bugs using the API.

I checked for the following conditions - which I understand as blocking expiration - https://help.launchpad.net/Bugs/Expiry.

task status not Incomplete
bug is not a duplicate
bug task is not assigned to someone
but task does not have a milestone
bug can_expire
date last updated is greater than 60 days ago

Using that criteria I couldn't find any bug tasks in the +expirable-bugs url that should not expire.

[Brian Murray (brian-murray)]

Manually reviewing some of the bugs that can expire in Ubuntu I noticed that some with patches are listed. Personally, I'd prefer that these did not expire if they meet all of other criteria as it'd be one extra place to look for bugs with patches.

[Ursula Junque (ursinha)]

Fixed in stable r10758 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10758>

[Abel Deuring (adeuring)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20.04.2010 18:00, Brian Murray wrote:
> I'm rather interested in this and seeing it enabled and working well.
> Subsequently, I wrote some launchpadlib code to double check expirable
> Ubuntu bug tasks and ensure that bugs really should expire.
> Incidentally, its rather unfortunate that there is no way to search for
> expirable bugs using the API.
>
> I checked for the following conditions - which I understand as blocking
> expiration - https://help.launchpad.net/Bugs/Expiry.
>
> task status not Incomplete
> bug is not a duplicate
> bug task is not assigned to someone
> but task does not have a milestone
> bug can_expire
> date last updated is greater than 60 days ago

Correct. There is an additional condition: All other bug tasks of a bug
must be in status invalid, won't fix or incomplete.

>
> Using that criteria I couldn't find any bug tasks in the +expirable-bugs
> url that should not expire.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFL0EDhekBPhm8NrtARAqLgAJ9gdADLjpqEe9v2iP/SiDLDBe7ULwCeP7hC
CcRL3vaupdFiav91NKW5L4w=
=U5GT
-----END PGP SIGNATURE-----

[Brian Murray (brian-murray)]

Abel - ah that's not obvious from https://help.launchpad.net/Bugs/Expiry which says "However, the bug will be removed from the bug expiry process entirely as soon as one of those communities marks it as confirmed." Perhaps that should be clarified.

[Ursula Junque (ursinha)]

Fixed in stable r10795 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10795>

[Deryck Hodge (deryck)]

persia noted on IRC that fixing bug 569298 and making it work for expired bugs too, i.e. toggle expired bugs to confirmed or new when the original reporter responds, might be nice to do before re-enabling automatic expiration. I like that idea, too.

[Bryce Harrington (bryce)]

I'm a very aggressive user of expiration and like brian am really looking forward to seeing this online again. I also love the new Expired state.

That said, I think mbp has some really good points. I suspect the source of the consternation is mainly lack of feeling "in control". In that context, requiring people to re-opt-in would emphasize that the bug supervisors control the expiration. Bug supervisors might be a tiny bit annoyed at having to re-opt-in, but are going to be much happier at having the feature working again, as it will save them lots of time. Also, when they see bugs start mass-expiring within a day or so of re-opting-in, they'll have the feeling that _they_ caused the bugs to expire.

Is it possible to detect *when* the toggle was set to allow bugs to expire? If so, then maybe honor the setting if it was set within the past few months, otherwise toggle it back to off and email the bug supervisor, "Since it's been a long time since you opted-in, we didn't want to startle you by suddenly turning it on. Would you mind re-confirming that you do want to have bugs expire automatically? Please go to..."

[Martin Pool (mbp)]

That's a good summary Bryce.

iirc deryck told me verbally that Malone will get supervisors to
reconfirm this before it starts.

--
Martin <http://launchpad.net/~mbp/>

[Deryck Hodge (deryck)]

Yes, just to confirm, we will toggle all settings to not expire bugs and send bug supervisors emails telling them we have done this, using language similar to Bryce suggests here. We'll play it safe rather than sorry, though I'm certain someone will get upset about us mucking about in settings like this. I am convinced now that it's worth being cautious, even with this risk.

Also, we are indeed going to fix the bug I mentioned above where we toggle status back out of Expired or Incomplete when the original reporter responds again to the bug. We will file a LEP to make sure we get the fix right and get good feedback on how this should work. Once this bug fix is in, we'll do the settings change on projects, send emails to bug supervisors, blog, and then after a week for people to react we will turn on the script to expire bugs.

[Martin Pool (mbp)]

On 2 June 2010 23:05, Curtis Hovey <email address hidden> wrote:
> ** Changed in: malone
>       Status: Fix Committed => Fix Released

So did this now happen? I don't recall getting mail about it, but
perhaps I just had no projects with it turned off. Just curious.

--
Martin

[Deryck Hodge (deryck)]

On Mon, Jun 28, 2010 at 8:27 PM, Martin Pool <email address hidden> wrote:
> So did this now happen? I don't recall getting mail about it, but
> perhaps I just had no projects with it turned off.  Just curious.
>

Hi, Martin.

The only thing released was the new EXPIRED status, which is only
settable via the API or the Janitor. Some people have been using
scripts to do their own expiry, but we're not doing this across
Launchpad yet. I'm crafting the communications plan this week
actually, and will confirm with jml late this week that it's a good
one. Then, we'll start communications next week, with the plan to
re-enable bug expiry sometime between the middle to end of July.

Sorry we didn't make this clear in the bug yet.

Cheers,
deryck