Doug Hellmann wrote:
> On Sep 23, 2014, at 5:18 AM, Thierry Carrez <> wrote:
>> Devananda van der Veen wrote:
>>> On Mon, Sep 22, 2014 at 2:27 PM, Doug Hellmann <> 
>>> wrote:
>>>> On Sep 22, 2014, at 5:10 PM, Devananda van der Veen 
>>>> <> 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.
> That’s the part that wasn’t clear. If we’re not “incubating” those projects, 
> then what criteria do we use to make decisions about the applications? Is a 
> declaration of intent enough?

In Monty's proposal, the big tent is pretty welcoming. The bar is "are
you one of us":

> Some examples of community that we care about: being on stackforge rather 
> than github; having a PTL who you elect rather than a BDFL; having meetings 
> on IRC. "Do any of the people who hack on the project also hack on any other 
> existing OpenStack projects, or are the people completely unconnected?" is a 
> potential social touchstone as well.
> All in all, meeting the requirements for "being one of us" is not 
> particularly hard, nor should it be.

It's a community values assessment... I don't see what "incubating"
would give us there, apart from preserving red tape.

Thierry Carrez (ttx)

OpenStack-dev mailing list

Reply via email to