have too much process sometimes the bug opener is not a developer, it might be some operator
or openstack user, they just want to get it done but they don't know more detail
so we can keep the wishlist and cleanup it and mark it invalid as you suggested
like 6 month or 1 year, but mark the bug which may contains valid request Invalid like [1] right after
we found it's not current supported seems too rush
[1]https://bugs.launchpad.net/bugs/1556756
-----Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: -----
To: openstack-dev@lists.openstack.org
From: Matt Riedemann <mrie...@linux.vnet.ibm.com>
Date: 03/15/2016 02:50PM
Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 3/15/2016 8:37 AM, Chris Dent wrote:
> On Tue, 15 Mar 2016, Markus Zoeller wrote:
>
>> Long story short, I'm in favor of abandoning the use of "wishlist"
>> as an importance in bug reports to track requests for enhancements.
>
> While I'm very much in favor of limiting the amount of time issues
> (of any sort) linger in launchpad[1] I worry that if we stop making
> "wishlist" available as an option then people who are not well
> informed about the complex system for achieving features in Nova
> will have no medium to get their ideas into the system. We want
> users to sometime be able to walk up, drop an idea and move on without
> having to be responsible for actually doing that work. If we insist
> that such ideas must go through the blueprint process then most
> ideas will be left unstated.
We do have a way for people to drop off RFEs/ideas for features without
actually providing design details, which is the backlog specs:
https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
>
> What I think we need to do instead is fix this problem:
>
>> * we don't have a process to transform wishlist bugs to blueprints
>
> such that we do have a process of some kind where a wishlist idea
> either gets an owner who starts the blueprint process (because it is
> just that cool) or dies from lack of attention.
>
> It's clear, though, that we already have a huge debt in bug/issue
> management so adding yet another task is hard to contemplate.
>
> I think we can address some of that by more quickly expiring bugs
> that have had no recent activity or attention, on the assumption
> that:
>
> * They will come back up again if they are good ideas or real bugs.
> * Lack of attention is a truthy signal of either lack of resources or lack
> of importance.
>
> What needs to happen is that fewer things which are not actionable
> or nobody is interested in show up when traversing the bugs looking
> for something to work on.
>
> I'm happy to help some of this become true, in part because of [1]
> below.
>
> [1] I've recently spent a bit of time chasing bugs tagged
> "scheduler" and far too many of them are so old that it's impossible
> to tell whether they matter any more, and many of them are confused
> by patches and people who have gone in and out of existence. It's
> challenging to tease out what can be done and the information has
> very little archival value. It should go off the radar. Having a
> bunch of stuff that looks like it needs to be done but never
> actually is is stop energy and depressing.
>
>
>
> __________________________________________________________________________
> 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
>
We need to shrink the nova bug backlog. I'd say any wishlist bugs that
are open for over a year (maybe even 6 months) should be marked Invalid
with a comment saying to file a blueprint or a backlog spec (with links
on how to do that).
--
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
From: Matt Riedemann <mrie...@linux.vnet.ibm.com>
Date: 03/15/2016 02:50PM
Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 3/15/2016 8:37 AM, Chris Dent wrote:
> On Tue, 15 Mar 2016, Markus Zoeller wrote:
>
>> Long story short, I'm in favor of abandoning the use of "wishlist"
>> as an importance in bug reports to track requests for enhancements.
>
> While I'm very much in favor of limiting the amount of time issues
> (of any sort) linger in launchpad[1] I worry that if we stop making
> "wishlist" available as an option then people who are not well
> informed about the complex system for achieving features in Nova
> will have no medium to get their ideas into the system. We want
> users to sometime be able to walk up, drop an idea and move on without
> having to be responsible for actually doing that work. If we insist
> that such ideas must go through the blueprint process then most
> ideas will be left unstated.
We do have a way for people to drop off RFEs/ideas for features without
actually providing design details, which is the backlog specs:
https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
>
> What I think we need to do instead is fix this problem:
>
>> * we don't have a process to transform wishlist bugs to blueprints
>
> such that we do have a process of some kind where a wishlist idea
> either gets an owner who starts the blueprint process (because it is
> just that cool) or dies from lack of attention.
>
> It's clear, though, that we already have a huge debt in bug/issue
> management so adding yet another task is hard to contemplate.
>
> I think we can address some of that by more quickly expiring bugs
> that have had no recent activity or attention, on the assumption
> that:
>
> * They will come back up again if they are good ideas or real bugs.
> * Lack of attention is a truthy signal of either lack of resources or lack
> of importance.
>
> What needs to happen is that fewer things which are not actionable
> or nobody is interested in show up when traversing the bugs looking
> for something to work on.
>
> I'm happy to help some of this become true, in part because of [1]
> below.
>
> [1] I've recently spent a bit of time chasing bugs tagged
> "scheduler" and far too many of them are so old that it's impossible
> to tell whether they matter any more, and many of them are confused
> by patches and people who have gone in and out of existence. It's
> challenging to tease out what can be done and the information has
> very little archival value. It should go off the radar. Having a
> bunch of stuff that looks like it needs to be done but never
> actually is is stop energy and depressing.
>
>
>
> __________________________________________________________________________
> 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
>
We need to shrink the nova bug backlog. I'd say any wishlist bugs that
are open for over a year (maybe even 6 months) should be marked Invalid
with a comment saying to file a blueprint or a backlog spec (with links
on how to do that).
--
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
__________________________________________________________________________ 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
