Open Stack

On 28/11/16 13:33 -0500, Doug Hellmann wrote:
>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.


These two are my preferred options so far. They both recognize drivers and allow
for this drivers to officially exist in the community. I like the idea of having
the drivers and services under the same team. I'd prefer them to have one PTL
and for there to be more interactions between driver owners and the rest of the
service team.

One thing that worries me about #6, which #5 solves, is that it doesn't clearly
identify drivers. We've had problems in the past communicating the status of
projects to other members, operators and end users. I'm worried that the quality
and stability of some of these drivers would affect a project's "reputation" (so
to speak). Proposal #6 says that project teams must host these drivers but they
are not really accountable for the drivers if they don't live in-tree (note this
could happen even for drivers that are in-tree).

The above is all to say that I'd feel more comfortable with proposal #6 if it
would provide a way to communicate that these repos are drivers, that they are
maintained by a subset of the bigger team, etc. This is something #5 solves by
clearly saying that some driver teams are different. This separation is not only
useful from a community perspective but also for managing these projects/repos.
It allows for setting a new set of rules instead of adding exceptions to the
existing ones.

What I don't like about #5 is that increases the complexity of the process for
adding new projects and it may make communication between these teams more
difficult. It will force the creation of tiny teams w/ all the things required
for teams to exist (PTL elections, ATC management, extra ATC, and what not).

At this point I think I'm leaning more towards #5 because it acknowledges these
drivers are useful but they are essentially managed by a different team, which
is something that #6 doesn't do.

I'll try to come up with some proposals to have #6 communicate this, unless it
was left out on purpose.

Thank you all for working on this,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161129/b2af9fa4/attachment.pgp>