On Sep 23, 2014, at 5:18 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Devananda van der Veen wrote:
>> On Mon, Sep 22, 2014 at 2:27 PM, Doug Hellmann <d...@doughellmann.com> wrote:
>>> On Sep 22, 2014, at 5:10 PM, Devananda van der Veen
>>> <devananda....@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.
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?
Doug
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
