Open Stack

On 15/03/16 16:21, "Markus Zoeller" <mzoeller at de.ibm.com> wrote:

>Sean Dague <sean at dague.net> wrote on 03/15/2016 02:52:47 PM:
>
>> From: Sean Dague <sean at dague.net>
>> To: openstack-dev at lists.openstack.org
>> Date: 03/15/2016 02:53 PM
>> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
>blueprint?
>> 
>> On 03/15/2016 09: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.
>> 
>> I believe that 0% of such drive by wishlist items ever get implemented.
>> I also think they mostly don't even get ACKed until 6 or 12 months after
>> submission. So It's not really a useful feedback channel.
>> 
>> So I'm pro just closing Wishlist items as Opinion and moving on.
>> Probably with some boiler plate around it about submission guidelines
>> for making a lightweight blueprint.
>
>A few more specific numbers which could help to make a decission.
>Open wishlist bug reports older than:
>>       now: 146
>>  6 months: 141
>> 12 months: 122
>
>Wishlist bug reports in progress: 9
>Wishlist bug reports implemented:
>    46 (last 24 months)
>    25 (last 18 months)
>    19 (last 12 months)
>     5 (last  6 months)
>
>Based on that it seems to me that it is not a very successful 
>channel to get ideas implemented(!). The dropping is easy though.
>
>Based on that I'm very much in favor of the agressive choice to close 
>the remaining 146 wishlist bugs with a comment which explains how to
>go on from there (using backlog specs).


The bug process was very light weight for an operator who found something they would like enhanced. It could be done through the web and did not require git/gerrit knowledge. I went through the process for a change:

- Reported a bug for the need to add an L2 cache size option for QEMU (https://bugs.launchpad.net/nova/+bug/1509304) closed as invalid since this was a feature request
- When this was closed, I followed the process and submitted a spec (https://blueprints.launchpad.net/nova/+spec/qcow2-l2-cache-size-configuration)

It was not clear how to proceed from here for me. 

The risk I see is that we are missing input to the development process in view of the complexity of submitting those requirements. Clearly, setting the bar too low means that there is no clear requirement statement etc. However, I think the combination of tools and assumption of knowledge of the process means that we are missing the opportunity for good quality input.

Many of these are low hanging fruit improvements which could be used to bring developers into the community if we can find a good way to get the input and match it with the resource to implement.

Tim

>
>> > 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.
>> 
>> Agreed. At 1000 open artifacts (many of them bad), you can't keep enough
>> context in your head at once to know things are really issues or not,
>> and once they get old enough they are lost to the mists of time. Having
>> a smaller high quality bug list would make it more of a todo list, which
>> would be nice for both experienced folks in the project, and new people
>> looking to contribute something off the bat.
>> 
>>    -Sean
>
>True, that's a goal we should aim for. The old bug reports bind
>unnecessarily resources. 
>
>Regards, Markus Zoeller (markus_z)
>
>
>__________________________________________________________________________
>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