Open Stack

On Sep 22, 2014, at 8:05 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:

> On Mon, Sep 22, 2014 at 2:27 PM, Doug Hellmann <doug at doughellmann.com> wrote:
>> 
>> On Sep 22, 2014, at 5:10 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:
>> 
>>> One of the primary effects of integration, as far as the release
>>> process is concerned, is being allowed to co-gate with other
>>> integrated projects, and having those projects accept your changes
>>> (integrate back with the other project). That shouldn't be a TC
>> 
>> The point of integration is to add the projects to the integrated *release*, not just the gate, because the release is the thing we have said is OpenStack. Integration was about our overall project identity and governance. The testing was a requirement to be accepted, not a goal.
> 
> We have plenty of things which are clearly part of OpenStack, and yet
> which are not part of the Integrated Release. Oslo. Devstack. Zuul...
> As far as I can tell, the only time when "integrated release" equals
> "the thing we say is OpenStack" is when we're talking about the
> trademark.
> 
>> Integration was about our overall project identity and governance. The testing was a requirement to be accepted, not a goal.
> 
> Project identity and governance are presently addressed by the
> creation of "Programs" and a fully-elected TC.  Integration is not
> addressing these things at all, as far as I can tell, though I agree
> that it was initially intended to.

Good point: I’m mixing terms here. Programs and projects have tended to be incubated at the same time. We’ve insisted that it doesn’t make sense to have a program if there is nothing being produced, and that a project can’t be incubated if the program isn’t also incubated. The fact that we’ve also had 1:1 coupling between programs and projects is unfortunate, but orthogonal to the fact that we have been evaluating the teams as well as the code.

> 
>> If there is no incubation process, and only a fixed list of projects will be in that new layer 1 group, then do contributors to the other projects have ATC status and vote for the TC? What is the basis for the TC accepting any responsibility for the project, and for the project agreeing to the TC’s leadership?
> 
> I think a good basis for this is simply whether the developers of the
> project are part of our community, doing things in the way that we do
> things, and want this to happen. Voting and ATC status is already
> decoupled [0] from the integrated gate and the integrated release --
> it's based on the accepted list of Programs [1], which actually has
> nothing to do with incubation or integration [2].

I’m concerned that we’re combining changes to the way we decide what we include in the gate with changes to the way we decide which groups of people have a say in how the overall OpenStack project is run. One is a technical discussion that has nothing at all to do with governance. The other is entirely about governance.

If we are no longer incubating *programs*, which are the teams of people who we would like to ensure are involved in OpenStack governance, then how do we make that decision? From a practical standpoint, how do we make a list of eligible voters for a TC election? Today we pull a list of committers from the git history from the projects associated with “official programs", but if we are dropping “official programs” we need some other way to build the list.

Doug

> 
> 
> -Devananda
> 
> [0] http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n132
> 
> [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml
> 
> [2] http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements.rst
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev