settingsLogin | Registersettings

[openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

0 votes

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.

I'd like to get rid of more clutter in our bug list to make it more
comprehensible by a human being. For this, I'm targeting our ~185 bug
reports which were reported 18 months ago and still aren't in progress.
That's around 37% of open bug reports which aren't in progress. This
post is about how and when I do it. If you have very strong reasons
to not do it, let me hear them.

When


I plan to do it in the week after the non-priority feature freeze.
That's week R-13, at the beginning of July. Until this date you can
comment on bug reports so they get spared from this cleanup (see below).
Beginning from R-13 until R-5 (Newton-3 milestone), we should have
enough time to gain some overview of the rest.

I also think it makes sense to make this a repeated effort, maybe after
each milestone/release or monthly or daily.

How


The bug reports which will be affected are:
* in status: [new, confirmed, triaged]
* AND without assignee
* AND created at: > 18 months
A preview of them can be found at [1].

You can spare bug reports if you leave a comment there which says
one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

The expired bug report will have:
* status: won't fix
* assignee: none
* importance: undecided
* a new comment which explains why this was done

The comment the expired bug reports will get:
This is an automated cleanup. This bug report got closed because
it is older than 18 months and there is no open code change to
fix this. After this time it is unlikely that the circumstances
which lead to the observed issue can be reproduced.
If you can reproduce it, please:
* reopen the bug report
* AND leave a comment "CONFIRMED FOR: "
Only still supported release names are valid.
valid example: CONFIRMED FOR: LIBERTY
invalid example: CONFIRMED FOR: KILO
* AND add the steps to reproduce the issue (if applicable)

Let me know if you think this comment gives enough information how to
handle this situation.

References:
[1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired

--
Regards, Markus Zoeller (markus_z)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 23, 2016 in openstack-dev by mzoeller_at_linux.vn (3,220 points)   3 6
retagged Jan 25, 2017 by admin

17 Responses

0 votes

On Mon, May 23, 2016 at 01:02:29PM +0200, Markus Zoeller wrote:
TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.

FWIW, I did the same thing in Cinder a while back and there weren't any
issues because of it raised to my attention. I agree that something that
old likely no longer is an issue, or probably has been fixed by a more
recent bug report or indirectly by another change.

I'd like to get rid of more clutter in our bug list to make it more
comprehensible by a human being. For this, I'm targeting our ~185 bug
reports which were reported 18 months ago and still aren't in progress.
That's around 37% of open bug reports which aren't in progress. This
post is about how and when I do it. If you have very strong reasons
to not do it, let me hear them.

When


I plan to do it in the week after the non-priority feature freeze.
That's week R-13, at the beginning of July. Until this date you can
comment on bug reports so they get spared from this cleanup (see below).
Beginning from R-13 until R-5 (Newton-3 milestone), we should have
enough time to gain some overview of the rest.

I also think it makes sense to make this a repeated effort, maybe after
each milestone/release or monthly or daily.

How


The bug reports which will be affected are:
* in status: [new, confirmed, triaged]
* AND without assignee
* AND created at: > 18 months
A preview of them can be found at [1].

You can spare bug reports if you leave a comment there which says
one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

The expired bug report will have:
* status: won't fix
* assignee: none
* importance: undecided
* a new comment which explains why this was done

The comment the expired bug reports will get:
This is an automated cleanup. This bug report got closed because
it is older than 18 months and there is no open code change to
fix this. After this time it is unlikely that the circumstances
which lead to the observed issue can be reproduced.
If you can reproduce it, please:
* reopen the bug report
* AND leave a comment "CONFIRMED FOR: "
Only still supported release names are valid.
valid example: CONFIRMED FOR: LIBERTY
invalid example: CONFIRMED FOR: KILO
* AND add the steps to reproduce the issue (if applicable)

Let me know if you think this comment gives enough information how to
handle this situation.

References:
[1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired

--
Regards, Markus Zoeller (markus_z)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 23, 2016 by Sean_McGinnis (11,820 points)   2 3 6
0 votes

Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different projects.

On 23 May 2016 at 14:02, Markus Zoeller mzoeller@linux.vnet.ibm.com wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.

I'd like to get rid of more clutter in our bug list to make it more
comprehensible by a human being. For this, I'm targeting our ~185 bug
reports which were reported 18 months ago and still aren't in progress.
That's around 37% of open bug reports which aren't in progress. This
post is about how and when I do it. If you have very strong reasons
to not do it, let me hear them.

When


I plan to do it in the week after the non-priority feature freeze.
That's week R-13, at the beginning of July. Until this date you can
comment on bug reports so they get spared from this cleanup (see below).
Beginning from R-13 until R-5 (Newton-3 milestone), we should have
enough time to gain some overview of the rest.

I also think it makes sense to make this a repeated effort, maybe after
each milestone/release or monthly or daily.

How


The bug reports which will be affected are:
* in status: [new, confirmed, triaged]
* AND without assignee
* AND created at: > 18 months
A preview of them can be found at [1].

You can spare bug reports if you leave a comment there which says
one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

The expired bug report will have:
* status: won't fix
* assignee: none
* importance: undecided
* a new comment which explains why this was done

The comment the expired bug reports will get:
This is an automated cleanup. This bug report got closed because
it is older than 18 months and there is no open code change to
fix this. After this time it is unlikely that the circumstances
which lead to the observed issue can be reproduced.
If you can reproduce it, please:
* reopen the bug report
* AND leave a comment "CONFIRMED FOR: "
Only still supported release names are valid.
valid example: CONFIRMED FOR: LIBERTY
invalid example: CONFIRMED FOR: KILO
* AND add the steps to reproduce the issue (if applicable)

Let me know if you think this comment gives enough information how to
handle this situation.

References:
[1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired

--
Regards, Markus Zoeller (markus_z)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
--
Duncan Thomas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2016 by Duncan_Thomas (16,160 points)   1 3 6
0 votes

On 24.05.2016 09:34, Duncan Thomas wrote:
Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different projects.

A first draft (without the actual expiring) is at [1]. I'm going to
finish it this week. If there is a place in an OpenStack repo, just give
me a pointer and I'll push a change.

On 23 May 2016 at 14:02, Markus Zoeller mzoeller@linux.vnet.ibm.com wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.
[...]

References:
[1]
https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py

--
Regards, Markus Zoeller (markus_z)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2016 by mzoeller_at_linux.vn (3,220 points)   3 6
0 votes

On Tue, May 24, 2016 at 11:00:35AM +0200, Markus Zoeller wrote:
On 24.05.2016 09:34, Duncan Thomas wrote:

Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different projects.

A first draft (without the actual expiring) is at [1]. I'm going to
finish it this week. If there is a place in an OpenStack repo, just give
me a pointer and I'll push a change.

FWIW I had to do a similar thing recently when I set all TripleO bugs
reported pre-liberty Incomplete - I ended up hacking up process_bugs.py
from release-tools:

https://github.com/openstack-infra/release-tools/blob/master/process_bugs.py

Perhaps we can adapt one of the scripts there (or add a new one if needed)
that can be used for several projects?

Here's a diff of my hacked-up version FWIW (I never got around to cleaning
it up and pushing it anywhere):

http://paste.fedoraproject.org/370318/14640938/

It shows how to add the comment and set the state, which you may be able to
reuse.

One thing I am unsure of is, can you actually force-expire bugs, or only
mark them incomplete and wait for launchpad to expire them (exact criteria
for this aren't that clear to me..)

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2016 by Steven_Hardy (16,900 points)   2 7 12
0 votes

On Tue, May 24, 2016 at 1:34 AM, Duncan Thomas duncan.thomas@gmail.com
wrote:

Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different projects.

​consistency sure seems like a nice thing to me.​

On 23 May 2016 at 14:02, Markus Zoeller mzoeller@linux.vnet.ibm.com
wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.

I'd like to get rid of more clutter in our bug list to make it more
comprehensible by a human being. For this, I'm targeting our ~185 bug
reports which were reported 18 months ago and still aren't in progress.
That's around 37% of open bug reports which aren't in progress. This
post is about how and when I do it. If you have very strong reasons
to not do it, let me hear them.

When


I plan to do it in the week after the non-priority feature freeze.
That's week R-13, at the beginning of July. Until this date you can
comment on bug reports so they get spared from this cleanup (see below).
Beginning from R-13 until R-5 (Newton-3 milestone), we should have
enough time to gain some overview of the rest.

I also think it makes sense to make this a repeated effort, maybe after
each milestone/release or monthly or daily.

How


The bug reports which will be affected are:
* in status: [new, confirmed, triaged]
* AND without assignee
* AND created at: > 18 months
A preview of them can be found at [1].

You can spare bug reports if you leave a comment there which says
one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

The expired bug report will have:
* status: won't fix
* assignee: none
* importance: undecided
* a new comment which explains why this was done

The comment the expired bug reports will get:
This is an automated cleanup. This bug report got closed because
it is older than 18 months and there is no open code change to
fix this. After this time it is unlikely that the circumstances
which lead to the observed issue can be reproduced.
If you can reproduce it, please:
* reopen the bug report
* AND leave a comment "CONFIRMED FOR: "
Only still supported release names are valid.
valid example: CONFIRMED FOR: LIBERTY
invalid example: CONFIRMED FOR: KILO
* AND add the steps to reproduce the issue (if applicable)

Let me know if you think this comment gives enough information how to
handle this situation.

References:
[1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired

--
Regards, Markus Zoeller (markus_z)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
--
Duncan Thomas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2016 by John_Griffith (8,640 points)   1 2 5
0 votes

Excerpts from Markus Zoeller's message of 2016-05-24 11:00:35 +0200:

On 24.05.2016 09:34, Duncan Thomas wrote:

Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different projects.

A first draft (without the actual expiring) is at [1]. I'm going to
finish it this week. If there is a place in an OpenStack repo, just give
me a pointer and I'll push a change.

On 23 May 2016 at 14:02, Markus Zoeller mzoeller@linux.vnet.ibm.com wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.
[...]

References:
[1]
https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py

Feel free to submit that to the openstack-infra/release-tools repo. We
have some other tools in that repo for managing launchpad bugs.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2016 by Doug_Hellmann (87,520 points)   4 5 13
0 votes

On 24.05.2016 19:05, Doug Hellmann wrote:
Excerpts from Markus Zoeller's message of 2016-05-24 11:00:35 +0200:

On 24.05.2016 09:34, Duncan Thomas wrote:

Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different projects.

A first draft (without the actual expiring) is at [1]. I'm going to
finish it this week. If there is a place in an OpenStack repo, just give
me a pointer and I'll push a change.

On 23 May 2016 at 14:02, Markus Zoeller mzoeller@linux.vnet.ibm.com wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.
[...]

References:
[1]
https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py

Feel free to submit that to the openstack-infra/release-tools repo. We
have some other tools in that repo for managing launchpad bugs.

Doug

Thanks! I pushed https://review.openstack.org/#/c/321008/

--
Regards, Markus Zoeller (markus_z)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 25, 2016 by mzoeller_at_linux.vn (3,220 points)   3 6
0 votes

(Top posting as a general reply to the thread)

Bugs are precious data. As much as it feels like the bug list is full of
cruft that won't ever get touched, one thing that we might be missing in
doing this is that the user who encounters the bug and takes the time
to actually find the bug tracker and report a bug, may be best served
by finding that somebody else has experienced something similar. If you
close this bug, that user is now going to be presented with the "I may
be the first person to report this" flow instead of "yeah I've seen that
error too!". The former can be a daunting task, but the latter provides
extra incentive to press forward, since clearly there are others who
need this, and more data is helpful to triagers and fixers.

I 100% support those who are managing bugs doing whatever they need
to do to make sure users' issues are being addressed as well as can be
done with the resources available. However, I would also urge everyone
to remember that the bug tracker is not only a way for developers to
manage the bugs, it is also a way for the community of dedicated users
to interact with the project as a whole.

Excerpts from Markus Zoeller's message of 2016-05-23 13:02:29 +0200:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.

I'd like to get rid of more clutter in our bug list to make it more
comprehensible by a human being. For this, I'm targeting our ~185 bug
reports which were reported 18 months ago and still aren't in progress.
That's around 37% of open bug reports which aren't in progress. This
post is about how and when I do it. If you have very strong reasons
to not do it, let me hear them.

When


I plan to do it in the week after the non-priority feature freeze.
That's week R-13, at the beginning of July. Until this date you can
comment on bug reports so they get spared from this cleanup (see below).
Beginning from R-13 until R-5 (Newton-3 milestone), we should have
enough time to gain some overview of the rest.

I also think it makes sense to make this a repeated effort, maybe after
each milestone/release or monthly or daily.

How


The bug reports which will be affected are:
* in status: [new, confirmed, triaged]
* AND without assignee
* AND created at: > 18 months
A preview of them can be found at [1].

You can spare bug reports if you leave a comment there which says
one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

The expired bug report will have:
* status: won't fix
* assignee: none
* importance: undecided
* a new comment which explains why this was done

The comment the expired bug reports will get:
This is an automated cleanup. This bug report got closed because
it is older than 18 months and there is no open code change to
fix this. After this time it is unlikely that the circumstances
which lead to the observed issue can be reproduced.
If you can reproduce it, please:
* reopen the bug report
* AND leave a comment "CONFIRMED FOR: "
Only still supported release names are valid.
valid example: CONFIRMED FOR: LIBERTY
invalid example: CONFIRMED FOR: KILO
* AND add the steps to reproduce the issue (if applicable)

Let me know if you think this comment gives enough information how to
handle this situation.

References:
[1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 30, 2016 by Clint_Byrum (40,940 points)   4 6 10
0 votes

On 24 May 2016 at 18:05, Doug Hellmann doug@doughellmann.com wrote:

Excerpts from Markus Zoeller's message of 2016-05-24 11:00:35 +0200:

On 24.05.2016 09:34, Duncan Thomas wrote:

Cinder bugs list was far more manageable once this had been done.

It is worth sharing the tool for this? I realise it's fairly trivial to
write one, but some standardisation on the comment format etc seems
valuable, particularly for Q/A folks who work between different
projects.

A first draft (without the actual expiring) is at [1]. I'm going to
finish it this week. If there is a place in an OpenStack repo, just give
me a pointer and I'll push a change.

On 23 May 2016 at 14:02, Markus Zoeller mzoeller@linux.vnet.ibm.com
wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.
[...]

References:
[1]

https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py
>

Feel free to submit that to the openstack-infra/release-tools repo. We
have some other tools in that repo for managing launchpad bugs.

Doug

Rather that blanket expiring old bugs, it might seem better to expire bugs
which are in non-triaged state which haven't had activity for >18 months.
This would seem like a less aggressive approach to closing issues which
haven't managed to reach triaged state and are otherwise stale.

This information is available in the API and i'd be happy to suggest a
review to change to this model if it is agreed.

Thanks

--
Kind Regards,
Dave Walker


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 30, 2016 by Dave_Walker (3,660 points)   1 4
0 votes

Clint Byrum wrote:
I 100% support those who are managing bugs doing whatever they need
to do to make sure users' issues are being addressed as well as can be
done with the resources available. However, I would also urge everyone
to remember that the bug tracker is not only a way for developers to
manage the bugs, it is also a way for the community of dedicated users
to interact with the project as a whole.

This is a classic dilemma in open source bug tracking: the data is
worthwhile, but keeping it around is generally making the tool less
usable as a task tracker to organize the work to be done. Most of it
comes from the fact that we are using the same tool ("bugs") for bug
reporting and task tracking, and those are different things. Most
developers want to use a task tracker to organize and prioritize their
work. They create "bugs" in Launchpad but what they are really doing is
creating a task for them (or an immediate peer) to process later. They
may look at bugs/tasks that someone outside the team creates, but that's
a completely different workflow. So the tension here is that the tool
presents unqualified user bugs in the same lists as qualified team tasks.

In a fully-controlled environment those tasks are separated. You have a
bug reporting system, which is mostly a collection of symptoms. Specific
squads of triagers work on verifying them, deduplicating them, giving
them some criticality, and checking them again after every release. You
also have a task tracking system, which is used by teams to organize
their work and assign it between team members. Team members create tasks
directly. They may look into the bug tracker for critical issues raised
by triagers and create tasks to address some of those critical bugs.

This works well, but it supposes that you have a tool that enables those
two workflows, and a triagers team to handle the first one. In open
source communities it's generally hard to find people to work purely on
symptoms triaging -- those who do tend to move to something more
rewarding very quickly. And the tools generally handle the distinction
between bug reporting and task tracking poorly... Which leads to the
dilemma of throwing out unqualified symptoms data to keep the tool
usable to organize work.

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 31, 2016 by Thierry_Carrez (57,480 points)   3 9 16
...