On 19/07/2016 16:39, Doug Hellmann 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?
"Staying that way" is certainly the impression given to users from other projects. In any case tempest is just an example. From my viewpoint, we need to make this a community default, to avoid even the short (which really ends up a long) term discrepancy between projects. If the standard in the community is equal access, this means when the next testing tool, CLI, SDK, $cross_project_tool comes along, it is available to all projects equally. If everyone uses the interfaces, they get better for all users of them, "big tent projects" and "tc-approved-release" alike. Having two way of doing the same thing means that there will always be discrepancies between people who are in the club, and those who are not. - Graham > 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
