Excerpts from Hayes, Graham's message of 2016-07-19 16:59:20 +0000: > 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.
OK, but is that an "impression" or is it a stated "policy"? > 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. Before we start making lots of specific rules about how teams coordinate, I would like to understand the problem those rules are meant to solve, so thank you for providing that example. I still haven't heard from the QA team, though. Ken'ichi? > 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. I think I understand your motivation. It's not clear yet whether there needs to be a new policy to change the existing intent, or if a discussion just hasn't happened, or if someone simply needs to edit some code. Are there other examples we can talk about in the mean time? 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
