On Thu, 2022-06-23 at 11:28 +0100, Stephen Finucane wrote:
I suspect we're trying to achieve two opposing goals here, at least as far as the tooling side of things goes. On one hand, we'd like to rely on the tooling that opendev provides - namely CI that handles cross-project dependencies (Zuul) and a powerful code review platform (Gerrit) - but we also don't want to alienate existing contributors to Gophercloud who have a negative opinion of Gerrit and don't wish to use it. We could build a system similar to what the SQLAlchemy folks have done (see e.g. [1]) but that requires time and energy and I wouldn't expect the OpenDev folks to do this, meaning we'd have to build and maintain it ourselves. Otherwise, without this kind of integration, the Gerrit/Zuul and GitHub systems couldn't really co-exist. As such, it seems unlikely that we're going to be able to have our cake and eat it too, and we'll have to pick one and deal with the consequences.
zuul has the ablity to monitor github repos for pull request including depend on suport. however based on a breif chat yesterday that is not considerd robust and is not somethign the infra tream can really commit to maintaining with there curent staffing. While there is not a grovernance resolution that i could find that state this it was my understandign that if you were to be an offical project within the openstack/openinfra governacne then gerrit for code review was requried and the offcal repo had to be hosted in the openinfrac repos. the github mirrors are just that mirros not the offical soruce. i think it would be harmful to the comunity to biforcate the code review workflow by usign differnt tooling per project honestly. i know many on the openstack side stongly dislike teh github workflow when we have had to use it instead of gerrit and i also unserdstn tha those who are used to the github workflow simialr dislike gerrit. i am not going to go into whihc is better or not but i obviosly am storngly biased towards gerrit having used github and gitlab for code review in the past but from a simpel standpoint of standardising our work flow i thinke we likely shoudl update the project testing interface and new project requirements to specify the use of gerrit offically going forward. https://github.com/openstack/governance/blob/master/reference/project-testin... https://github.com/openstack/governance/blob/master/reference/new-projects-r... i will note that the new project guid does say """ Releases of OpenStack deliverables are handled by the OpenStack Release Management team through the openstack/releases repository. Official projects are expected to relinquish direct tagging (and branch creation) rights in their Gerrit ACLs once their release jobs are functional.""" so it already has an implict assumtion that all new project will use gerrit it just does not spell that out explcitly.
Regarding the legal side of things, it _sounds_ like there's no big issue with regard to moving the project under the general OpenInfra umbrella but it'll be trickier to move it under the OpenStack project unless the tooling is also aligned. I don't know what the former would gain us and I suspect the latter won't gain us much either unless we align with tooling.
i woudl say based on the current resoltion that it cant become an offical openstack project without conformign to the new project requriemetn and ptg. i assume Gophercloud is written in go ? so this would be the pti doc for it https://github.com/openstack/governance/blob/master/reference/pti/golang.rst by the way being hosted by openinfra and being an offical openstack project under the governace of the tc and foundation are two differnt things. if Gophercloud just want to use the openinfra ci ectra on ther github repo or be added to x namespace which are unoffcial project that are hosted by openinfra outside fo openstack offical governacec the pti does not apply. i would see the adpoption of the pti and code review workflow as a blocker to includtionin openstack personally but im not a TC/foundation memeber.
Cheers, Stephen