[all][foundation][ecosystem] External projects under the foundation hat
smooney at redhat.com
Thu Jun 23 11:14:12 UTC 2022
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. ) 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.
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
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.
>  https://github.com/sqlalchemy/sqlalchemy/pull/7964
More information about the openstack-discuss