Open Stack

Boris Pavlovic wrote:
> it goes without saying that working on cross-project stuff in OpenStack
> is quite hard task. 
> 
> Because it's always hard to align something between a lot of people from
> different project. And when topic start being too "HOT"  the discussion
> goes in wrong direction and attempt to do cross project change fails, as
> a result maybe not *ideal* but *good enough* change in OpenStack will be
> abandoned. 
> 
> The another issue that we have are "specs". Projects are asking to make
> spec for change in their project, and in case of cross project stuff you
> need to make N similar specs (for every project). That is really hard to
> manage, and as a result you have N different specs that are describing
> the similar stuff. 
> 
> To make this process more formal, clear and simple, let's reuse process
> of "specs" but do it in one repo /openstack/cross-project-specs.
> 
> It means that every cross project topic: Unification of python clients,
> Unification of logging, profiling, debugging api, bunch of others will
> be discussed in one single place..

I think it's a good idea, as long as we truly limit it to cross-project
specs, that is, to concepts that may apply to every project. The
examples you mention are good ones. As a counterexample, if we have to
sketch a plan to solve communication between Nova and Neutron, I don't
think it would belong to that repository (it should live in whatever
project would have the most work to do).

> Process description of cross-project-specs:
> 
>   * PTL - person that mange core team members list and puts workflow +1
>     on accepted specs
>   * Every project have 1 core position (stackforge projects are included)
>   * Cores are chosen by project team, they task is to advocate project
>     team opinion 
>   * No more veto, and -2 votes
>   * If > 75% cores +1 spec it's accepted. It means that all project have
>     to accept this change.
>   * Accepted specs gret high priority blueprints in all projects

So I'm not sure you can force "all projects to accept the change".
Ideally, projects should see the benefits of alignment and adopt the
common spec. In our recent discussions we are also going towards more
freedom to projects, rather than less : imposing common specs to
stackforge projects sounds like a step backwards there.

Finally, I see some overlap with Oslo, which generally ends up
implementing most of the "common policy" into libraries it encourages
usage of. Therefore I'm not sure having a "cross-project" PTL makes
sense, as he would be stuck between the Oslo PTL and the Technical
Committee.

> With such simple rules we will simplify cross project work: 
> 
> 1) Fair rules for all projects, as every project has 1 core that has 1
> vote. 

A "project" is hardly a metric for fairness. Some projects are 50 times
bigger than others. What is a "project" in your mind ? A code repository
? Or more like a program (a collection of code repositories being worked
on by the same team ?)

So in summary, yes we need a place to discuss truly cross-project specs,
but I think it can't force decisions to all projects (especially
stackforge ones), and it can live within a larger-scope Oslo effort
and/or the Technical Committee.

-- 
Thierry Carrez (ttx)