[openstack-dev] [Neutron] Evolving the stadium concept

Armando M. armamig at gmail.com
Thu Dec 10 06:06:47 UTC 2015


On 9 December 2015 at 02:02, Thierry Carrez <thierry at openstack.org> wrote:

> Armando M. wrote:
> > For whom of you is interested in the conversation, the topic was brought
> > for discussion at the latest TC meeting [1]. Unfortunately I was unable
> > to join, however I would like to try and respond to some of the comments
> > made to clarify my position on the matter:
> >
> >> ttx: the neutron PTL say he can't vouch for anything in the neutron
> > "stadium"
> >
> > To be honest that's not entirely my position.
> > [...]
>
> I think I should have said "for everything" rather than "for anything" :)
>
>
ok, It makes more sense!

>> flaper87: I agree a driver should not be independent
> >
> > Why, what's your rationale? If we dig deeper, some drivers are small
> > code drops with no or untraceable maintainers. Some are actively
> > developed and can be fairly complex. The spectrum is pretty wide. Either
> > way, I think that preventing them from being independent in principle
> > may hurt the ones that can be pretty elaborated, and the ones that are
> > stale may hurt Neutron's reputation because we're the ones who are
> > supposed to look after them (after all didn't we vouch for them??)
> > [...]
>
> Yes, I agree with you that the line in the sand (between what should be
> independent and what should stay in neutron) should not be based on a
> technical classification, but on a community definition. The "big tent"
> is all about project teams - we judge if that team follows the OpenStack
> way, more than we judge what the team technically produces. As far as
> neutron goes, the question is not whether what the team produces is a
> plugin or a driver: the question is whether all the things are actually
> produced by the same team and the same leadership.


> If the teams producing those things overlap so significantly the Neutron
> leadership can vouch for them being done by "the neutron project team",
> they should stay in. If the subteams do not overlap, or follow different
> development practices, or have independent leadership, they are not
> produced by "the neutron project team" and should have their own
> independent project team.
>

I am glad you made this point, because some projects have clearly been a
spin-off sponsored by the same team and leadership, whilst others have not
(call it the new stuff if you will). However, people move on, when
technology tend to be the legacy, so I am not sure the judgement call
should be about teams rather than technology, but that's a different
conversation I suppose.

If that's the criteria, managing the growth (or lack thereof) of the
stadium becomes a problem of a different nature. However, before we do that
we'll have to figure out what to do with the growth that has occurred up
until now without taking this criteria into account to the letter!


>
> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151209/f645ea93/attachment-0001.html>


More information about the OpenStack-dev mailing list