<div dir="ltr">At the last TC meeting [1] we discussed this topic and the various options that were presented, here's a quick recap:<div><br></div><div>Options that will be removed, the patches for these options will be abandoned:</div><div><div> - Red (option 6), it had the least support<br></div><div> - Hard black (option 1) in favor of soft black (option 2)</div><div> - Hard white (option 3) in favor of soft white (option 4)</div><div><br></div><div>Remaining Options:</div><div> - Soft black (option 2): default option, had no negative feedback, represents the current status quo</div><div> - Soft white (option 4): had some positive feedback, folks liked it's simple solution</div><div> - Grey (option 5): had the most positive feedback, but also the least amount of detail</div></div><div><br></div><div>We'll continue to iterate on the remaining three options.</div><div><br></div><div> - steve</div><div><br></div><div>[1] <a href="http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt">http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 1:33 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The OpenStack community wants to encourage collaboration by emphasizing<br>
contributions to projects that abstract differences between<br>
vendor-specific products, while still empowering vendors to integrate<br>
their products with OpenStack through drivers that can be consumed<br>
by the abstraction layers.<br>
<br>
Some teams for projects that use drivers may not want to manage<br>
some or all of the drivers that can be consumed by their project<br>
because they have little insight into testing or debugging the code,<br>
or do not have the resources needed to manage centrally a large<br>
number of separate drivers. Vendors are of course free to produce<br>
drivers to integrate with OpenStack completely outside of the<br>
community, but because we value having the drivers as well as the<br>
more general support of vendor companies, we want to encourage a<br>
higher level of engagement by welcoming vendor-specific teams to<br>
be a part of our community governance.<br>
<br>
Our Requirements for New Projects list [0] includes a statement<br>
about establishing a "level and open collaboration playing field"<br>
<br>
The project shall provide a level and open collaboration playing<br>
field for all contributors. The project shall not benefit a single<br>
vendor, or a single vendors product offerings; nor advantage<br>
contributors from a single vendor organization due to access to<br>
source code, hardware, resources or other proprietary technology<br>
available only to those contributors.<br>
<br>
This requirement makes it difficult to support having teams focused<br>
on producing a deliverable that primarily benefits a single vendor.<br>
So, we have some tension between wanting to collaborate and have a<br>
level playing field, while wanting to control the amount of driver<br>
code that projects have to manage.<br>
<br>
I'm raising this as an issue because it's not just a hypothetical<br>
problem. The Cisco networking driver team, having been removed from<br>
the Neutron stadium, is asking for status as a separate official<br>
team [1]. I would very much like to find a way to say "yes, welcome<br>
(back)!"<br>
<br>
To that end, I've been working with fungi and ttx to identify all<br>
of our options. We've come up with a "spectrum", which I will try<br>
to summarize here but please read the associated governance patches<br>
for the full details. (Please note that although we've split up the<br>
work of writing the patches, each author may not necessarily support<br>
all of the patches he has submitted.)<br>
<br>
1. A resolution reaffirming the "level playing field" requirement,<br>
and acknowledging that it effectively precludes official status<br>
for teams which only develop drivers for proprietary systems<br>
(hard black) [2]<br>
<br>
This would have the immediate effect of denying the Cisco team's<br>
request, as well as precluding future requests from similar teams.<br>
<br>
2. A resolution reaffirming the "level playing field" requirement,<br>
and acknowledging that it does not necessarily preclude official<br>
status for teams which only develop drivers for proprietary<br>
systems (soft black) [3]<br>
<br>
This would allow driver-specific teams for systems as long as<br>
those drivers can be developed without access to proprietary<br>
information. The TC would have to consider how this applies to<br>
each team's request as it is evaluated.<br>
<br>
3. A resolution and policy change removing the "level playing field"<br>
requirement (hard white) [4]<br>
<br>
This would completely remove the problematic wording from the<br>
governance documents (eliminate the restriction on benefiting a<br>
single company and consider access to specific information for<br>
some contributors to not be a problem).<br>
<br>
4. A resolution and policy change loosening the "level playing field"<br>
requirement (soft white) [5]<br>
<br>
This would add an exception to the existing wording in the<br>
governance documents to exempt teams working only on drivers.<br>
They would still be subject to all of our other policies, unless<br>
similar exceptions are included.<br>
<br>
5. Consider driver teams to be a completely different animal, defined<br>
in drivers.yaml instead of projects.yaml (grey option) [6]<br>
<br>
This establishes drivers as second-order objects that are necessary<br>
for the success of the main projects, and for which requirements<br>
can be loosened. It would establish a new category of team without<br>
the level playing-field requirement and some of the other team<br>
requirements that seem not to apply to driver teams because they<br>
are essentially a public facet of a single vendor.<br>
<br>
6. A resolution requiring projects that consume drivers to host all<br>
proposed drivers. (red option) [7]<br>
<br>
This would require teams with projects providing driver interfaces<br>
to also host, in some form, drivers from vendors that ask for<br>
hosting. The drivers would not need to be in the main project<br>
repo, but would need to be in a repository "owned" by the project<br>
team. Project teams would not be considered responsible for the<br>
quality of the resulting drivers. Contributors to the driver<br>
repos would be considered part of the electorate for team PTL.<br>
<br>
7. A resolution proposing to allow driver-teams, without specifying<br>
any implementation details. [8]<br>
<br>
This may go along with option 2, 3, 4, or 5. It may also be used<br>
as the basis for an alternative proposal if we have missed an<br>
approach.<br>
<br>
We also need to consider while making the situation better that we<br>
not have a huge proliferation of these new teams. For example, some<br>
resources given to teams are finite (CI resources, space at PTGs<br>
and Summits, foundation staff support, cross-project team support).<br>
We also don't want to encourage driver authors to move their code<br>
out of projects that are willing to host them just because they<br>
can. Therefore, it is likely that even if we do allow driver teams<br>
in some form (options 2, 3, 4, and 5), they will have fewer rights<br>
than teams building abstraction layers that use the drivers.<br>
<br>
Again, these options are presented to give a more complete picture<br>
and not because we necessarily support all of them (obviously, some<br>
of them are clearly in conflict). I'll post my personal opinions<br>
in a follow up message to avoid editorializing here.<br>
<br>
Doug<br>
<br>
[0] <a href="http://governance.openstack.org/reference/new-projects-requirements.html" rel="noreferrer" target="_blank">http://governance.openstack.<wbr>org/reference/new-projects-<wbr>requirements.html</a> - requirements for new projects<br>
[1] <a href="https://review.openstack.org/363709" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>363709</a> - Add networking-cisco back into the Big Tent<br>
[2] <a href="https://review.openstack.org/403834" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403834</a> - Proprietary driver dev is unlevel<br>
[3] <a href="https://review.openstack.org/403836" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403836</a> - Driver development can be level<br>
[4] <a href="https://review.openstack.org/403838" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403838</a> - Stop requiring a level playing field<br>
[5] <a href="https://review.openstack.org/403839" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403839</a> - Level playing fields, except drivers<br>
[6] <a href="https://review.openstack.org/403829" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403829</a> - establish a new "driver team" concept<br>
[7] <a href="https://review.openstack.org/403830" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403830</a> - add resolution requiring teams to accept driver contributions<br>
[8] <a href="https://review.openstack.org/403826" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>403826</a> - add a resolution allowing teams based on vendor-specific drivers<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>