Open Stack

Devananda van der Veen 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.

The main goal of incubation, as we did it in the past cycles, is a
learning period where the new project aligns enough with the existing
ones so that it integrates with them (Horizon shows Sahara dashboard)
and won't break them around release time (stability, co-gate, respect of
release deadlines).

If we have a strict set of projects in layer #1, I don't see the point
of keeping incubation. We wouldn't add new projects to layer #1 (only
project splits which do not really require incubations), and additions
to the big tent are considered on social alignment only ("are you
vaguely about cloud and do you follow the OpenStack way"). If there is
nothing to graduate to, there is no need for incubation.

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

In Monty's proposal, ATC status would be linked to contributions to the
big tent. Projects apply to become part of it, subject themselves to the
oversight of the Technical Committee, and get the right to elect TC
members in return.

-- 
Thierry Carrez (ttx)