Open Stack

 ---- On Thu, 23 Jun 2022 06:14:12 -0500 Sean Mooney <smooney at redhat.com> wrote ----
 > 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-testing-interface.rst
 > https://github.com/openstack/governance/blob/master/reference/new-projects-requirements.rst
 > 
 > 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.

Yes, both are separate things and I think we are mixing both or at least if we have such impression or governance is
not so clear about it then we should fix it. I replied in another reply about governance point of view and IMO yes
we should allow such new projects hosted on new tooling or so but they need to make sure all the help on CI/CD,
release etc are taken care by them self or they help opendev team to support such things. If either of them cannot be
done and they do not fulfill the PTI or any other new project requirement criteria then they cannot be in OpenStack.

But overall, using different tooling should not be any barrier to be in OpenStack community. At some extend, we allowed
it for Skyline too (at least some way/process different there and we have accepted them as OpenStack project and given time
to work on things to do in OpenStack way).

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-June/029198.html

-gmann

 > 
 > > 
 > > Cheers,
 > > Stephen
 > > 
 > > [1] https://github.com/sqlalchemy/sqlalchemy/pull/7964
 > > 
 > > 
 > 
 > 
 >