<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 30, 2015, at 10:15 PM, Armando M. <<a href="mailto:armamig@gmail.com" class="">armamig@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On 30 November 2015 at 20:47, Doug Wiegley<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dougwig@parksidesoftware.com" target="_blank" class="">dougwig@parksidesoftware.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Nov 30, 2015, at 5:56 PM, Armando M. <<a href="mailto:armamig@gmail.com" target="_blank" class="">armamig@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hi folks,<div class=""><br class=""></div><div class="">The stadium concept was introduced more or less formally since April of this year. At the time it was introduced (see [1]), the list of deliverables included neutron, client, specs and *-aas services. As you may be well aware, 6+ months is a long time in the OpenStack world, and lots of things happened since then. The list has grown to [2]. </div><div class=""><span style="font-size: 12.8px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.8px;" class="">When I think about what 'deliverables' are, I am inclined to think that all of the projects that are part of the list will have to behave and follow the same rules, provided that there is flexibility given by the tags.<span class="Apple-converted-space"> </span></span><span style="font-size: 12.8px;" class="">However, reality has proven us that rules are somewhat difficult to follow and enforce, and some boundaries may be too strict for some initiatives to comply with. This is especially true if we go from a handful of projects that we had when this had started to the nearly the two dozens we have now.</span></div><div class=""><p style="font-size: 12.8px;" class="">As a result, there is quite an effort imposed on the PTL, the various liaisons (release, infra, docs, testing, etc) and the core team to help manage the existing relationships and to ensure that the picture stays coherent over time. <span style="font-size: 12.8px;" class="">Sometimes the decision of being part of this list is even presented before one can see any code, and that defeats the whole point of the deliverable association. </span><span style="font-size: 12.8px;" class="">I have experienced first hand that this has become a burden, and I fear that the stadium might be an extra layer of governance/complexity that could even interfere with the existing responsibilities of the TC and of OpenStack infra.</span></p><p style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">So my question is: would revisiting/clarifying the concept be due after some time we have seen it in action? I would like to think so. </span><span style="font-size: 12.8px;" class="">To be fair, I am not sure what the right answer is, but I know for a fact that some iterations are in order, and I like to make a proposal:</span></p><p style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">I would like to suggest that we evolve the structure of the Neutron governance, so that most of the deliverables that are now part of the Neutron stadium become</span><span style="font-size: 12.8px;" class=""> standalone projects that</span><span style="font-size: 12.8px;" class=""> are entirely self-governed (they have their own core/release teams, etc). </span><span style="font-size: 12.8px;" class="">In order to denote the initiatives that are related to Neutron I would like to present two new tags that projects can choose to label themselves with:</span></p></div></div></div></blockquote></span><div class="">Interesting proposal, and I’m just thinking out loud here. I’m generally in favor of separating the governance as we separate the dependencies, just because at some point what we’re doing doesn’t scale. To provide a little context, there are two points worth keeping in mind:</div><div class=""><br class=""></div><div class="">- The neutron stadium actually slightly pre-dates the big tent, and works around some earlier governance friction. So it may make less sense now in light of those changes.</div></div></div></blockquote><div class=""><br class=""></div><div class="">If my memory doesn't fail me, the first time I recall of talks about the big tent is September 2014, in this email thread:</div><div class=""><br class=""></div><div class=""><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html</a></div><div class=""><br class=""></div><div class="">So, no I don't think we were a novelty :)</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">- Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON* to be useful. These items are less useful to be considered standalone, as they need general oversight, co-gating, and such, to stay sane. As we break the massive coupling that exists, this point will get less and less relevant. </div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't think that requires the oversight of a single individual, but you're right that this point will fade away over time.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">- I think that part of the initial intent was that these small subprojects would have their own core teams, but be able to take advantage of the infrastructure that exists around neutron as a whole (specs, release team, stable team, co-gates, mentors).</div><div class=""><br class=""></div><div class="">For your proposal, are you suggesting:</div><div class=""><br class=""></div><div class="">1. That these projects are fully separate, with their own PTLs and everything, and just have tags that imply their neutron dependency? OR,</div></div></div></blockquote><div class=""><br class=""></div><div class="">My point is: the project decides what's best, I don't have to have an opinion :)</div></div></div></div></div></blockquote><div><br class=""></div><div>I don’t think you *have* to have an opinion in either scheme. That sounds self-imposed. Delegate it.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">If they want to signal a relationship with Neutron they can do so by choosing one of the two tags being proposed.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class="">2. That they stay stadium projects, but we use tags to differentiate them? Many already have different core teams and their own specs process.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Must there be a place where we are together that is not OpenStack already? And what would that together mean exactly? That's the conundrum I am trying to move away from....</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">Are there particular projects that add more overhead? Does your proposal make it easier to get code to our user base? Does it add a bunch of makework to fit into a new model (same question, really). Is the PTL overhead too high currently? Is the shed pink or blue? :-)</div></div></div></blockquote><div class=""><br class=""></div><div class="">Not sure what you're asking: this isn't just about overhead to a single or a small group of people. It's about arranging ourselves the best way possible in order to deal with growth: if there were to be an upper limit to the amount of projects we have to deal with, then things would be easier to predict and manage, but we're far from having that in sight, I think.</div></div></div></div></div></blockquote><div><br class=""></div><div>Right, I’m asking you what the day-to-day pain points are *today* from your perspective. Because we don’t see them the way that you do, and it’s very hard to evaluate what makes sense for growth without knowing the actual constraints. I’m interested in what’s not working, or where you see load increasing.</div><div><br class=""></div><div>We expected some release team efficiency with subprojects, is that not what we’re seeing? </div><div><br class=""></div><div>We expected mostly separate core teams that wouldn’t impact neutron, are we seeing something different? </div><div><br class=""></div><div>When we kicked drivers/plugins out of tree, we offered an “official” openstack repo to the tiny single dev drivers that likely wouldn’t make it in the tent; has that offer/desire changed?</div><div><br class=""></div><div>I expect that the launchpad/bug load might be increasing linearly; that joint bug bucket might not make any sense, regardless of the decision here.</div><div><br class=""></div><div>Do we envision an evolution of things splitting as they get bigger, or just blowing the concept up and going back to experimental or tent?</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><blockquote type="cite" class=""><div class=""><span class=""><div dir="ltr" class=""><div class=""><ul class=""><li class=""><span class="" style="font-size: 12.8px;">'use-neutron-system': this means that the project provides networking services by using a pre-deployed end-to-end neutron system as is. No modifications whatsoever.</span><br class=""></li><li class=""></li></ul></div></div></span></div></blockquote></div></div></blockquote></div></div></div></blockquote><div>I think this one might be covered by requirements.txt.</div><div><br class=""></div><div>Thanks,</div><div>doug</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">doug</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span class=""><div dir="ltr" class=""><div class=""><div style="font-size: 12.8px;" class=""><br class=""></div><ul class=""><li class=""><span style="font-size: 12.8px;" class="">'is-neutron-subsystem': this </span><span style="font-size: 12.8px;" class="">means that the project provides networking services by implementing an integral part (or parts) of an end-to-end neutron system. Examples are: a service plugin, an ML2 mech driver, a monolithic plugin, an agent etc. It's something an admin has to use in order to deploy Neutron in a certain configuration.</span></li><li class=""><span style="font-size: 12.8px;" class="">'use-neutron-system': this means that the project provides networking services by using a pre-deployed end-to-end neutron system as is. No modifications whatsoever.</span><br class=""></li></ul><div class=""><br class=""></div><p style="font-size: 12.8px;" class="">As a result, there is no oversight by the Neutron core team, the PTL or liasons, but that should not stop people from being involved if they choose to. We would not lose the important piece of information which is the association to Neutron, and at the same time that would relieve some of us from the onus of dealing with initiatives for which we lack enough context and ability of providing effective guidance.</p><p style="font-size: 12.8px;" class="">In the process, the core team should stay focused on breaking the coupling that still affects Neutron so that projects that depend on it can do so more reliably, and yet innovate more independently. If that means revisiting the Neutron's mission statement, we can discuss that too.</p><p class=""><span style="font-size: 12.8px;" class="">I am sure this hardly covers all the questions you may have at this point, but I would like to take the opportunity to start the conversation to see where people stand. Whichever the outcome, I think that we should strive for decentralizing responsibilities as much as we can in order to be scalable as a project and I think that the current arrangement prevents us from doing that.</span></p><p class=""><span style="font-size: 12.8px;" class="">Thanks for reading.</span></p><p class=""><span style="font-size: 12.8px;" class="">Armando </span><br class=""></p><div class=""><br class=""></div><div class=""><div class=""><span style="font-size: 12.8px;" class="">[1] <a href="https://github.com/openstack/governance/blob/april-2015-elections/reference/projects.yaml#L141" target="_blank" class="">https://github.com/openstack/governance/blob/april-2015-elections/reference/projects.yaml#L141</a></span></div><div class=""><span style="font-size: 12.8px;" class="">[2] <a href="https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2000" target="_blank" class="">https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2000</a></span></div></div></div></div></span><span class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></span></div></blockquote></div><br class=""></div><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""><br class=""></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">__________________________________________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">OpenStack Development Mailing List (not for usage questions)</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Unsubscribe:<span class="Apple-converted-space"> </span></span><a href="mailto:OpenStack-dev-request@lists.openstack.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">OpenStack-dev-request@lists.openstack.org</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">?subject:unsubscribe</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br class=""></body></html>