Open Stack

I'll rank my preferred solutions, because I don't actually like any of
them.

Excerpts from Doug Hellmann's message of 2016-11-28 13:33:56 -0500:

> 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.

Ideally this question wouldn't even need to be discussed because
teams would accept all drivers, in some form, because they recognize
the importance of contribution of drivers to the success of their
project and OpenStack as a whole. The result would be some drivers
in-tree and others in a separate repository, as described in option
6, without the TC requiring teams to accept the code. This would
encourage collaboration and stem the proliferation of extra teams,
which forestalls some of the issues we're anticipating with resources
at the PTG, Summit, etc.

I understand that the actual social interactions within some teams,
and between teams and contributors from vendors, hasn't been ideal,
but I'm still not convinced that the current path is the right
solution. It will not encourage anyone who is not contributing to
the common parts of a project to do so, and it sets the wrong tone
for the necessary future interactions that happen between contributors
discussing code at driver API boundaries.

The proposal Sean has for the Cinder team to allow a "class 2"
driver type that is basically marked as unsupported by the core
team seems like it's a good compromise and something we could do
in all projects to help users understand the support level of all
the drivers they use (with some of the implementation details to
be worked out).

> 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).

If there's no general agreement that teams should host driver
contributions, then I would prefer option 3, which simplifies our
rules instead of adding more. The TC can recognize when a single-vendor
project does not benefit the overall community, and reject it on
those grounds, while allowing driver development teams. We can manage
PTG space and other scarce resources using similar judgment.

> 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.

If we feel the need to codify the differences between two types of
teams, then I'll help refine some version of option 5 to do that.

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