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.
- 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. 
- 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
- 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 
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, 2) 
some criteria for maturity like documentation, test coverage and 
integration/dependency requirements, 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"?

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.

Getting this worked out before the Kilo release would be valuable, because 
having the “last” integrated release without a clear plan forward creates some 
real concerns for those running or productizing the software. Not all tags or 
implementation details need to be defined, of course, but we should be able to 
communicate a solid plan for the layers and categories of tags, as well as the 
different bodies who may be involved in defining tags (ops community, etc) 
before expanding. 


> On Mar 10, 2015, at 2:02 PM, Russell Bryant <rbry...@redhat.com> wrote:
> 
> On 03/10/2015 02:56 PM, Thierry Carrez wrote:
>> Russell Bryant wrote:
>>> One point of clarification:
>>> 
>>> On 03/10/2015 02:28 PM, Gabriel Hurley wrote:
>>>> Even more concerning is the sentiment of "projects we want to
>>>> consciously drop" from Russell's original email.
>>> 
>>> This was in reference to criteria defined in:
>>> 
>>> http://governance.openstack.org/reference/incubation-integration-requirements.html
>>> 
>>> For example, we previously had a strict requirement *against*
>>> duplication of functionality among OpenStack projects unless it was with
>>> intent and with a clear plan to replace the old thing.  In this new
>>> model, that would be a requirement we would consciously drop.
>> 
>> It's a requirement we *already* consciously dropped when we approved the
>> new projects requirements. Or do you mean you want to come back on that
>> decision[1]?
> 
> No, I don't want to come back on it.  It was obviously a poorly worded
> comment.  It was an attempt to say that I'd like it if we were closer to
> having tags that covered most of those requirements, except for the
> things we no longer care about, such as the example given.
> 
> -- 
> Russell Bryant
> 
> __________________________________________________________________________
> 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

Reply via email to