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