Excerpts from Doug Wiegley's message of 2016-07-19 13:58:59 -0600: > > > On Jul 19, 2016, at 9:36 AM, Doug Hellmann <d...@doughellmann.com> wrote: > > > > Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +0000: > >> On 18/07/2016 17:57, Thierry Carrez wrote: > >>> Hayes, Graham wrote: > >>>> [...] > >>>> The point is that we were supposed to be a level field as a community > >>>> but if we have examples like this, there is not a level playing field. > >>> > >>> While I generally agree on your goals here (avoid special-casing some > >>> projects in generic support projects like Tempest), I want to clarify > >>> what we meant by "level playing field" in a recent resolution. > >> > >> > >> Yes - it has been pointed out the title is probably overloading a term > >> just used for a different purpose - I am more than willing to change it. > >> > >> I wasn't sure where I got the name, and I realised that was probably in > >> my head from that resolution. > >> > >>> This was meant as a level playing field for contributors within a > >>> project, not a level playing field between projects. The idea is that > >>> any contributor joining any OpenStack project should not be technically > >>> limited compared to other contributors on the same project. So, no > >>> "secret sauce" that only a subset of developers on a project have access > >>> to. > >> > >> There is a correlation here - "special sauce" (not secret obviously) > >> that only a subset of projects have access to. > >> > >>> I think I understand where you're gong when you say that all projects > >>> should have equal chances, but keep in mind that (1) projects should not > >>> really "compete" against each other (but rather all projects should > >>> contribute to the success of OpenStack as a whole) and (2) some > >>> OpenStack projects will always be more equal than others (for example we > >>> require that every project integrates with Keystone, and I don't see > >>> that changing). > >> > >> Yes, I agree we should not be competing. But was should not be asking > >> the smaller projects to re-implement functionality, just because they > >> did not get integrated in time. > >> > >> We require all projects to integrate with keystone for auth, as we > >> require all projects to integrate with neutron for network operations > >> and designate for DNS, I just see it as a requirement for using the > >> other components of OpenStack for their defined purpose. > >> > > > > It would be useful to have some specific information from the QA/Tempest > > team (and any others with a similar situation) about whether the current > > situation about how differences between in-tree tests and plugin tests > > are allowed to use various APIs. For example, are there APIs only > > available to in-tree tests that are going to stay that way? Or is this > > just a matter of not having had time to "harden" or "certify" or > > otherwise prepare those APIs for plugins to use them? > > Doug, one example that I’m aware of — I’ve suggested moving neutron entirely > out of devstack and into the neutron repo, via the devstack plugin interface. > This was rejected, and the counter-argument given was that the folks that > maintain the integrated gate, which happen to be many of the same folks > maintaining devstack and the like, want to retain control of the items that > can break the integrated gate, and that it gets too hard to track down > individual project folks when the world is burning. > > I don’t personally agree with the decision, but I can see some merit in that > argument.
Yes, this is one of the outcomes of being in a situation where other projects require something as a dependency -- each side loses a little control, and some centralization happens to ensure that we can maintain the flow of work for OpenStack as a whole. Doug > > Thanks, > doug > > > > > Doug > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
