Open Stack

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
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/cd2e7fb4/attachment.html>