<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell <<a href="mailto:lauren@openstack.org">lauren@openstack.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dissolving the integrated release without having a solid plan and replacement is difficult to communicate to people who depend on OpenStack. We’re struggling on that front.<br>
<br>
That said, I’m still optimistic about project structure reform and think it could be beneficial to the development community and users if it’s executed well. It gives us the opportunity to focus on a tighter core of services that are stable, reliable and scalable, while also recognizing more innovation that’s already happening in the community, beyond the existing integrated release. Coming out of the ops meetup in Philadelphia yesterday, a few things were clear:<br>
<br>
- Operators don’t want the wild west. They are nervous about dissolving the integrated release, because they want a strong filter and rules - dependency mapping, release timing, test coverage - around the most widely adopted projects. I’m not sure we’re giving them a lot of confidence.<br></blockquote><div><br></div><div>We're not lowering the testing standards of existing projects... can you be more clear as to what is creating this concern?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- They also want some kind of bar or filter for community projects, to provide guidance beyond it’s in or out of the community. Tags can help with the nuances once they’re in the tent, but I think there’s some support for a bit higher bar overall.<br></blockquote><div><br></div><div>What would that bar look like? If what we have in new-project-requirements isn't enough, what changes are being suggested?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- That said, several people expressed they did not want duplication to prevent a project from making it into the tent. They would like to have options beyond the core set of projects<br></blockquote><div><br></div><div>Glad to hear that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The layers concept came back to play. It was clear there was a distinct dropoff in operators running projects other than nova, keystone, glance, cinder, horizon and neutron<br></blockquote><div><br></div><div>Not surprising....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The operators community is keen to help define and apply some tags, especially those relevant to maturity and stability and general operability<br>
<br>
(I know several of you were at the ops meetup, so please jump in if I’ve missed or misrepresented some of the feedback. Notes from the session <a href="https://etherpad.openstack.org/p/PHL-ops-tags" target="_blank">https://etherpad.openstack.<u></u>org/p/PHL-ops-tags</a>.)<br>
<br>
Based on feedback and conversations yesterday, I think it’s worth evolving the overall project criteria to add 1) a requirement for contributor diversity, </blockquote><div><br></div><div>Joe's got a proposal up for that already.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2) some criteria for maturity like documentation, test coverage and integration/dependency requirements, </blockquote><div><br></div><div>I don't think that should be a requirement for entry -- after all, these are still subjective judgements, subject to invalidation over time -- but I would like to see metadata (ie, tags) that describe a projects' current state, and can be updated by the community.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and 3) make sure there are no trademark issues with the project name, since it will be referred to as an OpenStack project. I’m also unclear how we’re planning to refer to these projects, as “Foo, an OpenStack community project” but not “OpenStack Foo"?<br></blockquote><div><br></div><div>That's a good question....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For tags, I think defining a set of projects based on a broad reference architecture / use case like "base compute” or “compute kernel” and “object storage” is critical. Those tags will imply the projects share common dependencies and are released together. If we categorize tags that can be applied, "compute kernel” could be a higher level category and more prominent. Defining those initial tags should provide enough direction and confidence to start considering new projects.<br>
<br></blockquote><div><br></div><div>I've started drafting some tags for "layers" or "use cases" -- I'm sure they'll get expanded on. I'll post a link once I've uploaded to gerrit.</div><div><br></div><div>--</div><div>Devananda</div></div></div>