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

[Markus Zoeller]

The expiration of old (stale) bug reports happened right now.

Stats:
# of bug reports before expiration: 826
# of expired bug reports:   188
# of bug reports after expiration:  638

That affected ~22% of our overall open bug reports and ~36% of bug
reports which are not in progress. You can see a graphical impact at
[1]. The list of affected bug reports is at [2] and as an attached file.

References:
[1] http://45.55.105.55:3000/dashboard/db/openstack-bugs
[2] http://paste.openstack.org/show/525937/

-- 
Regards, Markus Zoeller (markus_z)

On 21.06.2016 14:43, Markus Zoeller wrote:
> A reminder that this will happen in ~2 weeks.
> 
> Please note that 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
> 
> On 23.05.2016 13:02, 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.
>>
>>
>> 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
>>
> 
> 


+-+--+-+
|   Bug # | Title   
 | Age (d) |
+-+--+-+
|  933498 | "List Volumes" should support filtering 
 |1599 |
|  955792 | No public IP addresses listed in server representation  
 |1573 |
|  956589 | Device is  busy error on lxc instance shutdown  
 |1572 |
| 1018253 | No error message prompt during attaching when mountpoint is 
occupied |1462 |
| 1039665 | Creating Neutron L2 networks (without subnets) doesn't work as 
expected  |1413 |
| 1045248 | dhcp server defaults to gateway for filtering when unset
 |1401 |
| 1072734 | Improve instance state recovery for Compute service failure during 
Create Server |1344 |
| 1080278 | addFloatingIp multi-network  

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

[Markus Zoeller]

On 21.06.2016 18:24, Adam Young wrote:
> On 06/21/2016 08:43 AM, Markus Zoeller wrote:
>> A reminder that this will happen in ~2 weeks.
>>
>> Please note that 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
>>
>> On 23.05.2016 13:02, 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.
>>>
>>>
>>> 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
>>>
>>
> DONT TOUCH BUG 968696!
> 

I added a comment in the bug report (like described above) which keeps
it open until Newton goes EOL. If you see other bug reports you care
about, feel free to add a comment in their bug reports.

-- 
Regards, Markus Zoeller (markus_z)


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

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

[Adam Young]

On 06/21/2016 08:43 AM, Markus Zoeller wrote:

A reminder that this will happen in ~2 weeks.

Please note that 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

On 23.05.2016 13:02, 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.


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




DONT TOUCH BUG 968696!


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

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

[Markus Zoeller]

A reminder that this will happen in ~2 weeks.

Please note that 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

On 23.05.2016 13:02, 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.
> 
> 
> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 5/31/2016 7:35 AM, Sean Dague wrote:

On 05/30/2016 04:02 PM, Shoham Peller wrote:

I support Clint's comment, and as an example, only today I was able to
search a bug and to see it was reported 2 years ago and wasn't solved since.
I've commented on the bug saying it happened to me in an up-to-date nova.
I'm talking about a bug which is on your list -
https://bugs.launchpad.net/nova/+bug/1298075

I guess I wouldn't
 been able to do so if the bug was closed.


A closed bug still shows up in the search, and if you try to report a
bug. So you'd still see in in reporting.

That bug is actually a classic instance of something which shouldn't be
in the bug tracker. It's a known issue of all of OpenStack and
Keystone's token architecture. It requires a bunch of Keystone feature
work to be addressed.

Having a more public "Known Issues in OpenStack" googlable page might be
way more appropriate for this so we don't spend a ton of time
duplicating issues into these buckets.

-Sean



Heh, I opened that bug 2 years ago. And it's a duplicate of several bugs 
at this point and has a fix available, so I've marked it a duplicate of 
the bug that has the fix.


The main point of removing this old stuff is so we can actually see new 
things when doing triage, since we at least have some consistent triage 
for new bugs going on now.


Anyway, it's a drop in the bucket. A bug that's two years old with no 
one working on it to me means, meh, it's either not important or if 
someone cares and doesn't find it, they'll report a new bug (which 
should get triaged) and provide a fix if they care enough.


--

Thanks,

Matt Riedemann


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

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

[Sean Dague]

On 05/30/2016 04:02 PM, Shoham Peller wrote:
> I support Clint's comment, and as an example, only today I was able to
> search a bug and to see it was reported 2 years ago and wasn't solved since.
> I've commented on the bug saying it happened to me in an up-to-date nova.
> I'm talking about a bug which is on your list -
> https://bugs.launchpad.net/nova/+bug/1298075
> 
> I guess I wouldn't
>  been able to do so if the bug was closed.

A closed bug still shows up in the search, and if you try to report a
bug. So you'd still see in in reporting.

That bug is actually a classic instance of something which shouldn't be
in the bug tracker. It's a known issue of all of OpenStack and
Keystone's token architecture. It requires a bunch of Keystone feature
work to be addressed.

Having a more public "Known Issues in OpenStack" googlable page might be
way more appropriate for this so we don't spend a ton of time
duplicating issues into these buckets.

-Sean

-- 
Sean Dague
http://dague.net

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

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

[Sean Dague]

On 05/30/2016 02:37 PM, Clint Byrum wrote:
> (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 strongly disagree with this sentiment. Bugs are only useful if
actionable. Given the rate of change of the code base an 18 month old
bug without a reasonable reproduce case (which in almost all cases is
not there), is just debt. And more importantly they are sink holes where
well intended developers go off and burn 3 days realizing it's
completely irrelevant to the current project. Energy that could be spent
on relevant work.

> 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.

Dedicated users reporting bugs that are actionable tend not to exist
longer than the supported window of the project.

I do also suggest that if people feel strongly that bugs shouldn't be
expired like this, they put their money where their mouth is and help on
the Bug Triage and addressing bugs through the system. Because the
alternative to expiring old bugs isn't old bugs getting more eyes, it's
all bugs getting less time by developers because the pile is so
insurmountable no one ever wants to look at it.

-Sean

-- 
Sean Dague
http://dague.net

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

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

[Thierry Carrez]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dave Walker]

On 24 May 2016 at 18: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 
> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Shoham Peller]

I support Clint's comment, and as an example, only today I was able to
search a bug and to see it was reported 2 years ago and wasn't solved since.
I've commented on the bug saying it happened to me in an up-to-date nova.
I'm talking about a bug which is on your list -
https://bugs.launchpad.net/nova/+bug/1298075

I guess I wouldn't
 been able to do so if the bug was closed.

On Mon, May 30, 2016 at 9:37 PM, Clint Byrum  wrote:

> (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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Clint Byrum]

(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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Markus Zoeller]

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  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

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  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Griffith]

On Tue, May 24, 2016 at 1:34 AM, 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.
>
​consistency sure seems like a nice thing to me.​


>
> On 23 May 2016 at 14:02, 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.
>>
>>
>> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Steven Hardy]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Markus Zoeller]

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  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Duncan Thomas]

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  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean McGinnis]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev