[openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
mzoeller at de.ibm.com
Thu Mar 17 16:01:49 UTC 2016
The correct tldr:
TL;DR: Use the openstack-*ops* ML and discuss the most wanted RFEs at
Markus Zoeller/Germany/IBM wrote on 03/17/2016 04:57:27 PM:
> From: Markus Zoeller/Germany/IBM
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Date: 03/17/2016 04:57 PM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial)
> Top post as I summarize below what was said. At the end is a proposal
> of actions.
> TL;DR: Use the openstack-dev ML and discuss the most wanted RFEs at
> the summit?
> The two diametral points are:
> * The ops like to have a frictionless way for RFEs which need to be
> resolved explicitely (accepted|declined instead of 'starving to
> * The nova-bugs team wants to focus on faulty behavior of existing
> features only without the "noise" of RFEs.
> Just to make myself clear about my motivation and the conditions:
> * We have (almost) no volunteers for the "bug skimming duty"  to do
> a pre-sorting of reports (except auggy, she did/does an awesome job!)
> * We have (almost) no bug tag owners which do a deeper analysis of the
> incoming valid reports 
> * We have ~ 1000 bug reports open, a lot are (very) old and need
> * Some RFEs are not written like RFEs and the nova bugs team needs
> to figure out if this is a bug or an RFE. As I don't know every detail
> and have to research these details, it distracts a lot from real bugs
> * Some of the RFEs *need* a spec as they need a REST API change. Some
> need involvement of other projects like Cinder and Neutron.
> * I'm convinced that a low number of high quality features will help
> the ops in a better way than more features which work most of the
> This is not a criticism on the skill of the developers, bugs are a
> normal part of SW development and need to be fixed.
> * The resource restrictions described above force me (and others) to
> focus on the important things. I don't have the intention to exclude
> people's ideas.
> * I sometimes hear "Is OpenStack even Enterprise ready?". There is
> a lot ongoing with the project navigator and clear deprecation
> policies but without focusing on the quality aspect I have a hard
> time to say "yes, it is ready".
> * I don't care a lot about the overall number of bug reports. But it's
> not comprehensible anymore and setting a focus on bugs to fix first
> is not possible this way. Bringing the list back to a comprehensible
> size is the first step in adjusting the (fixes, reviews) pipeline.
> Finishing less items is more helpful than a lot of "in progress" items
> * I *do* want the ops feedback. I have the hope that ttx's proposal
> of the summit split  (which I support) will become *the* input
> channel for us.
> Alternative to wishlist bugs:
> I'm also subscribed to the "openstack-ops" mailing list (I assume most
> of us are). Posting a RFE on that list would have the following
> * It's the most easy way to post an idea (no Launchpad account needed)
> * Other ops can chime in if they want that or not. All without querying
> Launchpad for multiple projects.
> * You see RFE's for other projects too and can make conclusions if
> they maybe depend on or contradict each other.
> * The triaging effort for the bugs team for RFEs is none
> * The ML is (somewhat) queryable (just use [nova][RFE] in the subject)
> * The ops community can filter the top priority missing features by
> themselves before they reach out for implementation. Some ideas die
> naturally as other ops explain how they do it (=> share knowledge)
> The design summit can then have a session which goes through that list
> of pre-filtered most wanted ops features and take that into account
> when the priorization for the next cycle is done. This doesn't solve
> the challenge to find developers who implement that, but as these items
> will have more focus there could be more volunteers.
> This way could also be a good transition or supplement of the way
> we would do the requirements engineering after the (hopefully coming)
> split of the design summit. I'm not up-to-date how this is planned.
> Suggested action items:
> 1. I close the open wish list items older than 6 months (=138 reports)
> and explain in the closing comment that they are outdated and the
> ML should be used for future RFEs (as described above).
> 2. I post on the openstack-ops ML to explain why we do this
> 3. I change the Nova bug report template to explain this to avoid more
> RFEs in the bug report list in the future.
> 4. In 6 months I double-check the rest of the open wishlist bugs
> if they found developers, if not I'll close them too.
> 5. Continously double-check if wishlist bug reports get created
> Doubts? Thoughts? Concerns? Agreements?
>  https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
> Regards, Markus Zoeller (markus_z)
> Thierry Carrez <thierry at openstack.org> wrote on 03/16/2016 11:26:14 AM:
> > From: Thierry Carrez <thierry at openstack.org>
> > To: openstack-dev at lists.openstack.org
> > Date: 03/16/2016 11:27 AM
> > Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial)
> > Sean Dague wrote:
> > > It's a trade off. Would you rather keep Wishlist mechanism and have
> > > extra bugs in every release, and have to hunt for a new bug lead
> > > as often? That's my gut feel on the break down here.
> > >
> > > To get the bug backlog under control, we have to make hard calls
> > > This is one of them. Once we're working with < 400 open issues,
> > > to reopen the Wishlist mechanism is a thing we can and should
> > You're right that as soon as a project is resource-constrained (be it
> > patch authors, core reviewers bandwidth or spec reviewers) and you
> > get everything on your own list done anyway, you're likely to
> > stop looking at extra sources of inspiration. You start by ignoring
> > unqualified "wishlist bugs", then if you still can't get your own
> > done you'll likely ignore the more qualified "backlog specs" and if
> > else fails you'll start ignoring the bug reports altogether.
> > In an ideal world you'd either grow the resources / bandwidth, or get
> > the bottom of what you absolutely need to get done, and then start
> > paying attention to those feedback channels again. Those feedback
> > channels are essential to keep the pulse on the users problems and
> > needs, and avoid echo chamber effects. But then if you just can't give
> > them any attention, having them existing and ignored is worse than not
> > having them at all.
> > So if Nova currently is in that resource-constrained situation (and I
> > think it is), it's better to clearly set expectations and close the
> > wishlist bugs feedback mechanism, rather than keeping it open and
> > completely ignore it.
> > --
> > Thierry Carrez (ttx)
> > 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
More information about the OpenStack-dev