...
Ildiko Vancsa Release management guide in OpenStack: https://docs.openstack.org/project-team-guide/release-management.html. Big tent doesn’t have much to do with the OpenStack release models. The challenges with big tent was that we’ve been having a lot of projects and not everything was clearly fitting into the scope of OpenStack. Agree. It's more review and core developer issues. Well, that’s the project’s business on how they do onboarding and maintaining leadership. So I let the team members to judge the situation. :) With that said, there’s always room for improvement everywhere! Cedric Ollivier: Neutron could have simply promoted core developers rather than allow decreasing the review quality ;) However, OpenStack has had 10 years to work through all the issues. : https://docs.openstack.org/contributors/common/releases.html There are different release models within OpenStack to ensure the most efficient work and integration (need to release and maintain libraries, CLIs, APIs, etc). Gergely Csatari Just a bit of clarification to what we just discussed with Beth. OpenStack has a binary project status, the project is either an official OpenStack project or not (and it is decided by the OpenStack TC), however in OIF they have different states, like Confirmed and Pilot, but here it is not clear for me who decides on the state of the projects (my guess is the OIF board).
Ildiko Vancsa Yes, for top level projects (OpenStack, Airship, Kata Containers, etc) it is the OpenInfra Foundation Board of Directors who make the decision when a project gets accepted as confirmed project
From . From the stage of being pilot for some time firstAnd first. And as @Gergely said for OpenStack it is the TC (Technical Committee) who can accept a new project team to become part of OpenStack.
Jim Baker : One perspective I’d like to introduce is the role of the Anuket members in the two-phase release process. I think it essential that the spec writers are ACTIVELY involved in the acceptance/approval of the test release. The model of “write a spec, throw it over the wall” does not leverage the talent on the Anuket team. Can we figure out a process that keeps BOTH spec and test writers engaged in each others work product?
...