Sean Dague wrote:
It's a trade off. Would you rather keep Wishlist mechanism and have ~30
extra bugs in every release, and have to hunt for a new bug lead twice
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 here.
This is one of them. Once we're working with < 400 open issues, deciding
to reopen the Wishlist mechanism is a thing we can and should revisit.
You're right that as soon as a project is resource-constrained (be it
patch authors, core reviewers bandwidth or spec reviewers) and you can't
get everything on your own list done anyway, you're likely to gradually
stop looking at extra sources of inspiration. You start by ignoring the
unqualified "wishlist bugs", then if you still can't get your own things
done you'll likely ignore the more qualified "backlog specs" and if all
else fails you'll start ignoring the bug reports altogether.
In an ideal world you'd either grow the resources / bandwidth, or get to
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
