On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell <[email protected]> wrote:
> 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. > > 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: > > - 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. > We're not lowering the testing standards of existing projects... can you be more clear as to what is creating this concern? > - 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. > What would that bar look like? If what we have in new-project-requirements isn't enough, what changes are being suggested? > - 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 > Glad to hear that. > - 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 > Not surprising.... > - The operators community is keen to help define and apply some tags, > especially those relevant to maturity and stability and general operability > > (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 > https://etherpad.openstack.org/p/PHL-ops-tags.) > > Based on feedback and conversations yesterday, I think it’s worth evolving > the overall project criteria to add 1) a requirement for contributor > diversity, Joe's got a proposal up for that already. > 2) some criteria for maturity like documentation, test coverage and > integration/dependency requirements, 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. > 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"? > That's a good question.... > > 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. > > 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. -- Devananda
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
