tl;dr: we're not broken, but under stress...changing (outside) expectations requires changing the expression of the model...while it's called a 'stack' maybe it's multiple tiered stacks. MultiStack!
On Mon, Sep 22, 2014 at 4:27 PM, Doug Hellmann <d...@doughellmann.com> wrote: > The point of integration is to add the projects to the integrated > *release*, not just the gate, because the release is the thing we have said > is OpenStack. Integration was about our overall project identity and > governance. The testing was a requirement to be accepted, not a goal. > > If there is no incubation process, and only a fixed list of projects will > be in that new layer 1 group, then do contributors to the other projects > have ATC status and vote for the TC? What is the basis for the TC accepting > any responsibility for the project, and for the project agreeing to the > TC’s leadership? > This is one reason for multiple layers. The original 4 layer stack was meant as a technical dependency stack but has morphed into a social/project organizational stack. I don't think it is total coincidence that the technical hierarchy was interpreted as a social/governance hierarchy by some as there is a lot of similarity. The mapping between the two in my mind is fairly easy, but those details is not what is important. We love to look at the Apache Foundation for inspiration. In the current set of Apache projects most of them are not focused on adding value to a web server. They grew beyond that in multiple directions. I'm selfish and want to keep the layer nomenclature for the technical organization that helped re-structure DevStack and propose we think of these as *thing* where we have Multiple *Things*: * IaaS thing: the stuff that builds excellent clouds * PaaS thing: the stuff that does amazing things that may or may not be built on top of excellent clouds * XaaS thing(s): more things I can not visualize through the fog of antihistamines * Non-aas developer things: what enables us s developers to make the above things (infra, qa, etc) * Non-aas consumer things: what enables the rest of the world to enjoy the above things (docs, SDKs, clients, etc) This separates the technical hierarchical from the organizational relationships. All of the above things are still called OpenStack. But maybe it's a 'MultiStack'. - New projects wanting to join can apply and receive a 'provisional' attribute that tells the world we (OpenStack people) thing this looks promising and want to see if it matures to our standards. Similar to incubation but maybe the bar has some differences between the things. It _should_ require a higher bar to add to the foundation than a new deck on the side. - The integrated release still applies to a subset of the projects and/or things. The IaaS thing establishes the base release cycle other things apply common sense and follow along or release more often. - The test matrix is built using the technical layers and not the above organizational structure. I'm getting a bit hand-wavy here, but the point is to clearly state to the world that it isn't the organizational things that determine testing beyond having at least the 'provisional' attribute on a project. If the above feels very familiar it should. Some of it is terminology changes to help change expectations and some divisions based on use cases. What we have isn't totally broken, it is under growth related stress. Taking a different perspective on it will help expose where things can be improved. And what we are doing right. dt  TODO: cut-n-paste in actual allegorical noun  Yuck, better word here too! -- Dean Troyer dtro...@gmail.com
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev