[openstack-dev] Avoiding regression in project governance
Devananda van der Veen
devananda.vdv at gmail.com
Tue Mar 10 23:00:21 UTC 2015
On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell <lauren at openstack.org> 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
> - 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
> Based on feedback and conversations yesterday, I think it’s worth evolving
> the overall project criteria to add 1) a requirement for contributor
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev