Open Stack

Le 15/03/2016 14:48, Matt Riedemann a écrit :
>
>
> 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
>

I tend to agree, we could just put either opinion/wishlist or 
invalid/wishlist and gently ask the bug reporter to open at least a 
blueprint.

I'm not sure a backlog spec for a tiny RFE is worthwhile, because it 
would generate a lot of changes up to nova-specs tho, but in case we see 
some Launchpad blueprint needing a backlog spec, we could then invalid 
the blueprint and ask for a backlog spec instead.

-Sylvain

>>
>> 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-request at 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).
>