On 3/17/2016 1:26 PM, Tim Bell wrote:
On 17/03/16 18:29, "Sean Dague" <s...@dague.net> wrote:
On 03/17/2016 11:57 AM, Markus Zoeller wrote:
<snip>
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?
This sounds like a very reasonable plan to me. Thanks for summarizing
all the concerns and coming up with a pretty balanced plan here. +1.
-Sean
I’d recommend running it by the -ops* list along with the RFE proposal. I think
many of the cases
had been raised since people did not have the skills/know how to proceed.
Engaging with the ops list would also bring in the product working group who
could potentially
help out on the next step (i.e. identifying the best places to invest for RFEs)
and the other
topical working groups (e.g. Telco, scientific) who could help with
prioritisation/triage.
I don’t think that a launchpad account on its own is a big problem. Thus, I
could also see an approach
where a blueprint was created in launchpad with some reasonably structured set
of chapters. My
personal experience was that the challenges came more later on trying to get
the review matched up and
the right bp directories.
There is a big benefit to good visibility in the -ops community for RFEs
though. Quite often, the
features are implemented but people did not know how to find them in the doc
(or maybe its a doc bug).
Equally, the OSops scripts repo can give people workarounds while the requested
feature is in the
priority queue.
It would be a very interesting topic to kick off in the ops list and then have
a further review in
Austin to agree how to proceed.
Tim
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
I agree with Tim and Sean. As noted in my PTL candidacy email, I want an
ops CPL for the nova team, someone that can attend the ops meeting(s?)
and bring back issues.
I try to add known ops people that are involved in nova to specs for
their input when possible, but a lot of the time this ends up being Chet
Burgess for everything (Mr Nova Ops!). But we need to get a better
communication channel going with the ops list/channel/meetings and RFE
bugs aren't cutting it.
I like the idea of starting in the ML (dev or ops) since, as noted, if
it's already done, or someone has already implemented it out of tree and
just haven't had the time to push it to nova (which is more common than
you'd think), it can be noted quickly. It would also foster early
discussion on the idea before it shows up in gerrit as a spec review
where only a small handful of spec reviewers are going to see it (which
is also a reason things move slowly). If something was a bad idea, or
just didn't get much enthusiasm, then it kind of dies on the vine
naturally in the ML rather than a bitrot spec review in gerrit that we
just end up abandoning every 6 months.
--
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
