...
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 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. 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). And
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 the stage of being pilot for some time firstAnd 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?
...
Scott Steinbrueckis proposing a release cycle that maps to twice a year, by creating a release package. Each project (workstream) aligns with the package as appropriate for their pace. Discussion on how to fold all the project into the overall cycle properly.
Summary: There is a relatively tightly coupling between RM and RA. The others (RI and RC) are more loosely coupled. Look at OpenStack's experience in managing multiple work steams and projects in a big tent. We should make a decision to move forward. Let's try something and see how it goes. Next iteration will let us improve the process. Use agile methodologies!