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 __________________________________________________________________________ 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
