On Sep 19, 2014, at 6:29 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Monty Taylor wrote: >> I've recently been thinking a lot about Sean's Layers stuff. So I wrote >> a blog post which Jim Blair and Devananda were kind enough to help me edit. >> >> http://inaugust.com/post/108 > > Hey Monty, > > As you can imagine, I read that post with great attention. I generally > like the concept of a tightly integrated, limited-by-design layer #1 > (I'd personally call it "Ring 0") and a large collection of "OpenStack" > things gravitating around it. That would at least solve the attraction > of the integrated release, suppress the need for incubation, foster I’m not sure I see this change reducing the number of incubated projects unless we no longer incubate and graduate projects at all. Would everything just live on stackforge and have a quality designation instead of an “officialness” designation? Or would we have both? ATC status seems to imply we need some sort of officialness designation, as you mention below. > competition/innovation within our community, and generally address the > problem of community scaling. There are a few details on the > consequences though, and in those as always the devil lurks. > > ## The Technical Committee > > The Technical Committee is defined in the OpenStack bylaws, and is the > representation of the contributors to "the project". Teams work on code > repositories, and at some point ask their work to be recognized as part > of "OpenStack". In doing so, they place their work under the oversight > of the Technical Committee. In return, team members get to participate > in electing the technical committee members (they become "ATC"). It's a > balanced system, where both parties need to agree: the TC can't force > itself as overseer of a random project, and a random project can't just > decide by itself it is "OpenStack". > > I don't see your proposal breaking that balanced system, but it changes > its dynamics a bit. The big tent would contain a lot more members. And > while the TC would arguably bring a significant share of its attention > to Ring 0, its voters constituency would mostly consist of developers > who do not participate in Ring 0 development. I don't really see it as > changing dramatically the membership of the TC, but it's a consequence > worth mentioning. > > ## Programs > > Programs were created relatively recently as a way to describe which > teams are "in OpenStack" vs. which ones aren't. They directly tie into > the ATC system: if you contribute to code repositories under a blessed > program, then you're an ATC, you vote in TC elections and the TC has > some oversight over your code repositories. Previously, this was granted > at a code repository level, but that failed to give flexibility for > teams to organize their code in the most convenient manner for them. So > we started to bless teams rather than specific code repositories. > > Now, that didn't work out so well. Some programs were a 'theme', like > Infrastructure, or Docs. For those, competing efforts do not really make > sense: there can only be one, and competition should happen inside those > efforts rather than outside. Some programs were a 'team', like > Orchestration/Heat or Deployment/TripleO. And that's where the model > started to break: some new orchestration things need space, but the > current Heat team is not really interested in maintaining them. What's > the point of being under the same program then ? And TripleO is not the > only way to deploy OpenStack, but its mere existence (and name) > prevented other flowers to bloom in our community. > > You don't talk much about programs in your proposal. In particular, you > only mention layer 1, "Cloud Native" applications, "User Interface" > applications, and "Operator" applications. So I'm unsure of where, if > anywhere, would "Infrastructure" or "Docs" repositories live. > > Here is how I see it could work. We could keep 'theme' programs (think > Infra, Release cycle management, Docs, QA) with their current structure > (collection of code repositories under a single team/PTL). We would get > rid of 'team' programs completely, and just have a registry of > "OpenStack" code repositories (openstack*/*, big tent). Each of those > could have a specific PTL, or explicitely inherit its PTL from another > code repository. Under that PTL, they could have separate or same core > review team, whatever maps reality and how they want to work (so we > could say that openstack/python-novaclient inherits its PTL from > openstack/nova and doesn't need a specific one). That would allow us to > map anything that may come in. Oslo falls a bit in between, could be > considered a 'theme' program or several repos sharing PTL. I like the idea of chartered programs as a way to tackling our cross-project issues. We need fewer of programs, but for the ones we do need we still need to integrate them with the rest of our governance. > > ## The release and the development cycle > > You touch briefly on the consequences of your model for the "common > release" and our development cycle. Obviously we would release the ring > 0 projects in an integrated manner on a time-based schedule. > > For the other projects, we have a choice: > > - the "ring 0" model (development milestones, coordinated final release) > - the "Swift" model (release as-needed, coordinated final release) > - the "Oslo" model (release as-needed, try to have one final one before > end of cycle) > - the "Client libraries" model (release as-needed) > > If possible, I would like to avoid the "Swift" model, which is the most > costly from a release management standpoint. All projects following the > ring 0 model are easy to keep track of, using common freezes etc. So > it's easy to make sure they will be ready in time for the coordinated > release. Each project following the Swift model would be a special case, > and that adds up to a lot of load on the release management team. > Keeping track of one project doing that is OK. 5 or 20, not so much. So > I'd advise we only keep ring0, Oslo and client lib models as options. > Release management would just care about ring 0, and provide tools and > advice for all the others, but not being responsible for them. > > What about the development cycle ? I think it's part of our "identity": > being "OpenStack" is also about having the same notion of passing time, > the same reference points. So I think it would probably be a good idea, > even for projects that purely release "as-needed", to organize their > development at least vaguely around the notion of a common cycle. +1 — This is why we do it for Oslo. > > ## The design summit > > I'm not a big fan of your #11 suggestion. I guess I just don't want to > defer all in-project alignment and work to mid-cycle meetups, and force > all contributors to travel all the time. I think the right time to reach > alignment on the goals is at the start of a development cycle, not in > the middle of it. The middle of a cycle is a good time to get things > done. So I would still like teams to be able to discuss their goals at > the Design Summit, at the start of a cycle. > > Now I realize this creates a pretty significant issue, since Design > Summit space is one resource which can't really support the "infinite > tent" model. My proposal to solve it would be to give ample space to > cross-project issues, ring 0 projects, and 'theme' programs. Everyone > else gets limited space, which may boil down to a pod. Then we work on > options, so that whoever who wants to organize a large meetup in > parallel with the summit may find space to do so in neighboring hotels. > > The main value in that proposal is that it makes the "Design Summit" > space needs more predictable. I've been visiting spaces for the 2016 and > 2018 summits recently -- it's really difficult to make plans when you > don't know how many projects you'll have to host. And it's really > difficult to get good locations and times (and prices) if you don't book > at least 2 years in advance. > > ## The Foundation bylaws > > There are a number of terms used in the bylaws, and we may need to map > our new structure to it, make sure it doesn't require a bylaws change. > I didn't spot any showstopper yet. The "integrated release" could be the > ring 0 (that would mean that defcore would only get to pick between > Nova/Neutron/Cinder/Keystone/Designate for the trademark programs). The > "OpenStack project" could be the big tent. We keep the TC, the ATCs > concepts the same. > > > That was a long answer, but then so was your original post :P > > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev