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  from the integrated gate and the integrated release -- > it's based on the accepted list of Programs , which actually has > nothing to do with incubation or integration . 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) _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev