Open Stack

Excerpts from Flavio Percoco's message of 2016-11-29 17:19:15 +0100:
> 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.

I agree that clearly documenting who supports each driver, and how
tightly integrated that team is with the core team will be important.
That will be the case no matter what solution we pick (even saying
that drivers aren't official isn't going to avoid questions about
how well supported a driver is). I left the details of how to do
that up to the individual teams, since I know some are already
working on it.

Doug

> 
> Thank you all for working on this,
> Flavio
>