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

2016-05-30 Thread Vincent Legoll 

I'm open for suggestions to make this sound better. Thanks for this
feedback.


That's OK for me, +1 on the other comments in the thread.

--
Vincent Legoll
EGI FedCloud task force
Cloud Computing at IdGC
France Grilles / CNRS / IPHC

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Joseph Bajin 
All the different projects have different ways of reporting bugs and
looking for features.

You can see a few of the different ways that the Operators discussed back
at the Summit here -
https://etherpad.openstack.org/p/AUS-ops-Requests-for-Enhancement-Process

That should give you some more context on how to look for adding
bugs/feedback.

--Joe

On Fri, May 27, 2016 at 2:40 PM, Robert Starmer  wrote:

> Seems like a great approach.  You might want to also include:
>
> This bug was probably not triaged due to lack of information to reproduce
> the issue.  Please include as much information about the problem including
> steps to allow a developer to reproduce the issue in order for your time in
> reporting it to be useful for the community!
>
> Is there a 'best practice for reporting a bug' document somewhere, it'd
> likely be very useful to include a link in lieu of a message like the one
> above...
>
> R
>
> On Fri, May 27, 2016 at 9:59 AM, Markus Zoeller <
> mzoel...@linux.vnet.ibm.com> wrote:
>
>> On 27.05.2016 15:47, Vincent Legoll wrote:
>> > Hello,
>> >
>> > Le 27/05/2016 15:25, Markus Zoeller a écrit :
>> >> I don't see a benefit in leaving very old bug reports open when nobody
>> >> is working on it (again, a resource problem). Closing it (with "Won't
>> >> Fix") is explicit and easy to query. The information is not lost. This
>> >> does*not*  mean we don't care about the reported issues. It's simply
>> >> just more than we can currently handle.
>> >
>> > Are you sure "won't fix" is the right message you want to convey to the
>> > users that at least came to report something ?
>> >
>> > Isn't there an "expired" status or something else better suited ?
>> >
>> > "Won't fix" is a very strong message for a user.
>> >
>> > At least put a message explaining this is not really "we don't want to
>> > fix it" but "we expired old stale bugs"...
>> >
>>
>> You're right, there is a status "Expired" which can be set by a script
>> (but not the web UI). I don't have a strong reason to not use it.
>>
>> As explained in the original email, I intend to add this comment to the
>> expired bug reports:
>>
>>  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)
>>
>> I'm open for suggestions to make this sound better. Thanks for this
>> feedback.
>>
>> --
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Joshua Harlow 
Ya, I'd like to make sure that whoever starts applying these messages to 
bugs automagically takes into account that people may (or may not have) 
spent a lot of (personal or other) time reporting a bug and take that 
into account when producing a polite and thankful message to those that 
have gone through that effort (whatever it may have been).


IMHO be nice and considerate and understand that for some folks making a 
bug is a bunch of work and be clear that the bug is being closed, not 
because we don't value there work that was put into that bug...


-Josh

Robert Starmer wrote:

Seems like a great approach.  You might want to also include:

This bug was probably not triaged due to lack of information to
reproduce the issue.  Please include as much information about the
problem including steps to allow a developer to reproduce the issue in
order for your time in reporting it to be useful for the community!

Is there a 'best practice for reporting a bug' document somewhere, it'd
likely be very useful to include a link in lieu of a message like the
one above...

R

On Fri, May 27, 2016 at 9:59 AM, Markus Zoeller
> wrote:

On 27.05.2016 15 :47, Vincent Legoll wrote:
>  Hello,
>
>  Le 27/05/2016 15:25, Markus Zoeller a écrit :
> > I don't see a benefit in leaving very old bug reports open when
nobody
> > is working on it (again, a resource problem). Closing it (with "Won't
> > Fix") is explicit and easy to query. The information is not lost.
This
> > does*not*  mean we don't care about the reported issues. It's simply
> > just more than we can currently handle.
>
>  Are you sure "won't fix" is the right message you want to convey
to the
>  users that at least came to report something ?
>
>  Isn't there an "expired" status or something else better suited ?
>
>  "Won't fix" is a very strong message for a user.
>
>  At least put a message explaining this is not really "we don't want to
>  fix it" but "we expired old stale bugs"...
>

You're right, there is a status "Expired" which can be set by a script
(but not the web UI). I don't have a strong reason to not use it.

As explained in the original email, I intend to add this comment to the
expired bug reports:

  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)

I'm open for suggestions to make this sound better. Thanks for this
feedback.

--
Regards, Markus Zoeller (markus_z)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Robert Starmer 
Seems like a great approach.  You might want to also include:

This bug was probably not triaged due to lack of information to reproduce
the issue.  Please include as much information about the problem including
steps to allow a developer to reproduce the issue in order for your time in
reporting it to be useful for the community!

Is there a 'best practice for reporting a bug' document somewhere, it'd
likely be very useful to include a link in lieu of a message like the one
above...

R

On Fri, May 27, 2016 at 9:59 AM, Markus Zoeller  wrote:

> On 27.05.2016 15:47, Vincent Legoll wrote:
> > Hello,
> >
> > Le 27/05/2016 15:25, Markus Zoeller a écrit :
> >> I don't see a benefit in leaving very old bug reports open when nobody
> >> is working on it (again, a resource problem). Closing it (with "Won't
> >> Fix") is explicit and easy to query. The information is not lost. This
> >> does*not*  mean we don't care about the reported issues. It's simply
> >> just more than we can currently handle.
> >
> > Are you sure "won't fix" is the right message you want to convey to the
> > users that at least came to report something ?
> >
> > Isn't there an "expired" status or something else better suited ?
> >
> > "Won't fix" is a very strong message for a user.
> >
> > At least put a message explaining this is not really "we don't want to
> > fix it" but "we expired old stale bugs"...
> >
>
> You're right, there is a status "Expired" which can be set by a script
> (but not the web UI). I don't have a strong reason to not use it.
>
> As explained in the original email, I intend to add this comment to the
> expired bug reports:
>
>  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)
>
> I'm open for suggestions to make this sound better. Thanks for this
> feedback.
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Aubrey Wells 
Minor, but "This bug report has been closed [...]" sounds much better than
"This bug report got closed [...]"


-
Aubrey Wells
Manager, Network Operations
Digium Cloud Services
Main: 888.305.3850
Support: 877.344.4861 or http://www.digium.com/en/support


On Fri, May 27, 2016 at 10:59 AM, Markus Zoeller <
mzoel...@linux.vnet.ibm.com> wrote:

> On 27.05.2016 15:47, Vincent Legoll wrote:
> > Hello,
> >
> > Le 27/05/2016 15:25, Markus Zoeller a écrit :
> >> I don't see a benefit in leaving very old bug reports open when nobody
> >> is working on it (again, a resource problem). Closing it (with "Won't
> >> Fix") is explicit and easy to query. The information is not lost. This
> >> does*not*  mean we don't care about the reported issues. It's simply
> >> just more than we can currently handle.
> >
> > Are you sure "won't fix" is the right message you want to convey to the
> > users that at least came to report something ?
> >
> > Isn't there an "expired" status or something else better suited ?
> >
> > "Won't fix" is a very strong message for a user.
> >
> > At least put a message explaining this is not really "we don't want to
> > fix it" but "we expired old stale bugs"...
> >
>
> You're right, there is a status "Expired" which can be set by a script
> (but not the web UI). I don't have a strong reason to not use it.
>
> As explained in the original email, I intend to add this comment to the
> expired bug reports:
>
>  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)
>
> I'm open for suggestions to make this sound better. Thanks for this
> feedback.
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Markus Zoeller 
On 27.05.2016 15:47, Vincent Legoll wrote:
> Hello,
> 
> Le 27/05/2016 15:25, Markus Zoeller a écrit :
>> I don't see a benefit in leaving very old bug reports open when nobody
>> is working on it (again, a resource problem). Closing it (with "Won't
>> Fix") is explicit and easy to query. The information is not lost. This
>> does*not*  mean we don't care about the reported issues. It's simply
>> just more than we can currently handle.
> 
> Are you sure "won't fix" is the right message you want to convey to the
> users that at least came to report something ?
> 
> Isn't there an "expired" status or something else better suited ?
> 
> "Won't fix" is a very strong message for a user.
> 
> At least put a message explaining this is not really "we don't want to
> fix it" but "we expired old stale bugs"...
> 

You're right, there is a status "Expired" which can be set by a script
(but not the web UI). I don't have a strong reason to not use it.

As explained in the original email, I intend to add this comment to the
expired bug reports:

 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)

I'm open for suggestions to make this sound better. Thanks for this
feedback.

-- 
Regards, Markus Zoeller (markus_z)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Vincent Legoll 

Hello,

Le 27/05/2016 15:25, Markus Zoeller a écrit :

I don't see a benefit in leaving very old bug reports open when nobody
is working on it (again, a resource problem). Closing it (with "Won't
Fix") is explicit and easy to query. The information is not lost. This
does*not*  mean we don't care about the reported issues. It's simply
just more than we can currently handle.


Are you sure "won't fix" is the right message you want to convey to the
users that at least came to report something ?

Isn't there an "expired" status or something else better suited ?

"Won't fix" is a very strong message for a user.

At least put a message explaining this is not really "we don't want to
fix it" but "we expired old stale bugs"...

--
Vincent Legoll
EGI FedCloud task force
Cloud Computing at IdGC
France Grilles / CNRS / IPHC

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

2016-05-27 Thread Markus Zoeller 
Maybe a few more words on this ML *why* I'm doing this. It all comes
down to a simple resource problem. Far more bug reports get filed than
solved. For the last 3 releases the numbers [1][2][3] are:

Kilo   Liberty   Mitaka
Filed Bugs: 1144   926  968
Resolved Bugs:   722   570  524

The unresolved bug reports accumulate over time. Finding people to work
on those is nearly impossible. Some of the reasons are:
* a lot of the bug reports don't provide clear steps to reproduce the
  issue
* information about the setup/configuration/version(s) is missing
* not enough developers with a deep knowledge of Nova and its history

>From my point of the view, the bug list should serve as a tool to
*improve* Nova. This doesn't work if it's impossible to have an overview
of the things that are broken. The more current the affected version of
Nova is, the more likely it is that it gets solved.

I don't see a benefit in leaving very old bug reports open when nobody
is working on it (again, a resource problem). Closing it (with "Won't
Fix") is explicit and easy to query. The information is not lost. This
does *not* mean we don't care about the reported issues. It's simply
just more than we can currently handle.


References:
[1]
http://stackalytics.com/?metric=resolved-bugs=nova-group=kilo
[2]
http://stackalytics.com/?metric=resolved-bugs=nova-group=liberty
[3]
http://stackalytics.com/?metric=resolved-bugs=nova-group=mitaka

-- 
Regards, Markus Zoeller (markus_z)

On 24.05.2016 04:11, Tom Fifield wrote:
> FYI - if you have a bug that's been around forever in nova, please 
> follow Markus' instructions
> 
> 
>  Forwarded Message 
> Subject: [openstack-dev] [nova] I'm going to expire open bug reports 
> older than 18 months.
> Date: Mon, 23 May 2016 13:02:29 +0200
> From: Markus Zoeller 
> Reply-To: OpenStack Development Mailing List (not for usage questions) 
> 
> To: openstack-...@lists.openstack.org
> 
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators