Hello,

My $0.02.

If gophercloud is an sdk project solely for openstack clouds (which it looks like it does), I don't see it so different than the (python) SDK we have in governance in terms of scope. As SDKs should ideally have feature parity, it makes more sense to me to group them under a same openstack team.

On top of that, being under the openstack governance will bring a certain consistency (coherence), especially in terms of testability (="This SDK version works well with this code, we've tested them together"). Please note that I don't talk about testing/development tools in this previous sentence.

Yet, this doesn't seem to work with the current contributors/contributions (different ways of working to start with). So I think the following questions need a clear answer: 1) Do the openstack governance close the door to "different way of working", or do we change governance to allow official projects to NOT be hosted in OpenDev? (Other way to ask this question: Should we allow freedom for the contributors to chose what they want to use as "forge", as long as they are matching a common "interface" (=PTI)?) 2) If we want to change governance for more inclusivity of non-opendev projects, what do we need to change? (Side note: I only see a reference of openstack testing infrastructure in [1], with a mention "Where appropriate", did I miss something?). 3) Is the gophercloud project ready to adapt to the PTI for go [2]? 4) If no, what are the reasons? Would it make sense to review if the PTI [0][2] is still accurate?

Some of those questions are relevant for the TC, hence I updated the title with [tc] tag. Good luck on bringing this forward!

Regards, JP Evrard

[0]: https://governance.openstack.org/tc/reference/project-testing-interface.html [1]: https://governance.openstack.org/tc/reference/new-projects-requirements.html [2]: https://governance.openstack.org/tc/reference/pti/golang.html

---- On Wed, 22 Jun 2022 07:57:29 -0500 JP E openstack@a.spamming.party wrote ----

Hello,

My $0.02.

If gophercloud is an sdk project solely for openstack clouds (which it looks like it does), I don't see it so different than the (python) SDK we have in governance in terms of scope. As SDKs should ideally have feature parity, it makes more sense to me to group them under a same openstack team.

On top of that, being under the openstack governance will bring a certain consistency (coherence), especially in terms of testability (="This SDK version works well with this code, we've tested them together"). Please note that I don't talk about testing/development tools in this previous sentence.

Yet, this doesn't seem to work with the current contributors/contributions (different ways of working to start with).

Thanks for bringing it and asking the question, I think all are very valid questions and this is something we should be preparing the answer/policy as there might be more such project requests in future.

So I think the following questions need a clear answer:

1. Do the openstack governance close the door to "different way of working", or do we change governance to allow official projects to NOT be hosted in OpenDev? (Other way to ask this question: Should we allow freedom for the contributors to chose what they want to use as "forge", as long as they are matching a common "interface" (=PTI)?)

No, we do not close the door to "different way of working". We are open to ideas/project as long as it aligns with the OpenStack mission.

2. If we want to change governance for more inclusivity of non-opendev projects, what do we need to change?

(Side note: I only see a reference of openstack testing infrastructure in [1], with a mention "Where appropriate", did I miss something?).

AFAIK, there is no governance requirement from OpenStack to have the project be hosted on OpenDev, nor from OpenInfra Foundation/Bylaws (that is why not all Open Infra projects are on OpenDev). So I do not think we need any change in the governance because we do not even have such restrictions.

Yes, there are always best efforts or guidelines to use the Open Source tooling in Open Source development but in reality that cannot be true for many reasons including, technical challenges, different country/company IT policies or so. Not all Open Source tooling can be accessed from everywhere. One good example of this is video call tooling. TC, PTG, Board, and Foundation use/rely on the non-open source tool (zoom, google meet etc). I am not starting the discussion of using the Open Source tool in the video meeting or why all these teams are not using it which is a separate discussion but I am trying to say using 100% Open Source tools in Open source development is a little far from now. We need to adjust ourselves here and there.

3. Is the gophercloud project ready to adapt to the PTI for go [2]?
4. If no, what are the reasons? Would it make sense to review if the PTI [0][2] is still accurate?

Some of those questions are relevant for the TC, hence I updated the title with [tc] tag.

The question here is not about whether OpenStack Governance allows it or not (because we do not disallow it at least) instead, the question should be how feasible (technical challenges not process challenges) it will be to host non-opendev projects in OpenStack which is what is being discussed in the thread in other replies. This is the first case (if I remember correctly ) where we are asked about OpenStack's new project on non-opendev tooling so we need to see the possibility. I think a few of the questions back to the new project wanted to be non-opendev (gophercloud team) can be:

- If using a different tool than Gerrit, there is more possibility that you will not get help from other existing developers using Gerrit. Many of us keep helping every project on common things like fixing CI/CD, common changes, goal changes etc. If you are using very different tooling for code management then it will be difficult to get that help. But if you are using some common very known tooling like GitHub then it should be ok.

- You might have some challenges for CI/CD or I will say need to have your own set of tooling to test/debug the code, release the code or so. What tooling you will be using or making sure you satisfy all the requirements for OpenStack PTI.

- There might be some other common services like requirement management, and stable releases maintenance or so you would not get and end up doing it in your own way. Or help and extend these services' scope.

Basically, you might not get all the common help you get from the OpenStack supporting team or OpenDev tooling and if that is all ok then I do not think we should have any issue hosting you in OpenStack. Instead of such future requests, we should have more clarity in OpenStack governance document about what you need to do if not OpenDev hosted project.

-gmann

Good luck on bringing this forward!

Regards, JP Evrard

Jeremy Stanley wrote:

On 2022-06-22 16:30:47 -0500 (-0500), Ghanshyam Mann wrote: [...]

...

AFAIK, there is no governance requirement from OpenStack to have the project be hosted on OpenDev, nor from OpenInfra Foundation/Bylaws (that is why not all Open Infra projects are on OpenDev). So I do not think we need any change in the governance because we do not even have such restrictions.

[...]

If that's the consensus of the TC, then I recommend updating https://opendev.org/openstack/governance/src/branch/master/reference/new-pro... (particularly the parts where it says "The project uses public code reviews on the OpenStack infrastructure" and "The project has core reviewers and adopts a test-driven gate in the OpenStack infrastructure for changes").

Another thing to take into account is release management: I don't think the release team will support releases that bridge across different toolchains... one is plenty enough work for our small team.

That's not a "no" since we already have official openstack components that are released externally (openstack-puppet modules for example). The line we've been holding is that the center of the map[1] (OpenStack proper) is part of the "openstack" release, which has to be coordinated by the release team, and therefore has to all be on OpenDev. The other boxes (operations tooling, lifecycle management, operations tooling, client tools, integration enablers) don't necessarily have to. Those can be released independently (and off-cycle), and I guess could potentially be developed elsewhere, if the TC is comfortable with that.

[1] https://www.openstack.org/openstack-map

On 2022-06-23 12:00:58 -0500 (-0500), Ghanshyam Mann wrote:

Jeremy Stanley wrote:

[...]

...

...

If that's the consensus of the TC, then I recommend updating https://opendev.org/openstack/governance/src/branch/master/reference/new-pro... (particularly the parts where it says "The project uses public code reviews on the OpenStack infrastructure" and "The project has core reviewers and adopts a test-driven gate in the OpenStack infrastructure for changes").

Yes, that is what I mean that we have not explicitly said it has to be on OpenDev tooling as must requirement but yes we need to update the governance documentation also to have a clear view if "no opendev tooling then what are governance requirement"

[...]

I'm not sure who "we" is in this context, but the TC has "explicitly said it has to be on OpenDev tooling as must requirement" through the passages I quoted above (the referenced document absolutely states this, and was ratified by the TC). Removing that restriction is a substantive change to OpenStack's governing documents, not a mere clarification.

---- On Fri, 24 Jun 2022 03:25:08 -0500 Thierry Carrez thierry@openstack.org wrote ---

Jeremy Stanley wrote:

...

On 2022-06-23 12:00:58 -0500 (-0500), Ghanshyam Mann wrote:

...

Yes, that is what I mean that we have not explicitly said it has to be on OpenDev tooling as must requirement but yes we need to update the governance documentation also to have a clear view if "no opendev tooling then what are governance requirement"

[...]

I'm not sure who "we" is in this context, but the TC has "explicitly said it has to be on OpenDev tooling as must requirement" through the passages I quoted above (the referenced document absolutely states this, and was ratified by the TC). Removing that restriction is a substantive change to OpenStack's governing documents, not a mere clarification.

Well, I will not say those statements mentioned on the 'new project application' page are different from "project has to be hosted on OpenDev" but at the same time, they are not exactly the same. There is a difference between the "OpenStack Infrastructure" mentioned in that document since there was no OpenDev and now when OpenDev is a separate governing body than OpenStack. At least it is not just renaming the word "Open Infrastructure" to "OpenDev" directly but we should discuss if that can be something from OpenStack governance like "TACT" SIG or OpenDev directly. At least discuss, agree and explicitly state that so that we do not have any confusion or have the same question (like this thread) in future. or Even if in future new people maintaining OpenStack and not aware that Open Infrastructure became OpenDev may have more confusion on these two term.

I agree.. Historically, the TC has had a very strong stance that we should not fragment the community onto multiple platforms (for communication or development) or languages (for code or speech). The stated goal was to reinforce that OpenStack is a single project you join (and elect TC members to steward), rather than a loose coalition of several separate projects making independent choices.

So allowing different development platforms would definitely be a step in a whole new direction, and a pretty significant change. I'd expect a discussion on allowing different parallel communication platforms to follow next.

True, I do not deny that fact but I am saying there are changes in the situation and a good user-facing OpenStack tool is asking if they can be part of OpenStack or not but on the different tools, they want to maintain their code.

The question is accept that request or deny it, If deny from an OpenStack perspective then can we have that as a separate project under OpenInfra where there is no strict requirement of being hosted on OpenDev. Why we need to think about it because it is a beneficial tooling for OpenStack users.

-gmann

-- Thierry Carrez (ttx)

On 22. Jun 2022, at 15:12, Jeremy Stanley fungi@yuggoth.org wrote:

On 2022-06-22 10:12:16 +0200 (+0200), Artem Goncharov wrote: [...]

...

I went multiple times through explaining “change” model to both experienced and unexperienced people and is usually painful.

And you also have less trouble explaining the convoluted GitHub "pull request" workflow to someone who has never heard of Git or GitHub?

Yes, I do. And there are much less people who has never heard of GitHub.

...

In the Outreachy we also have same practice each time and this is for people just harder to understand (I see project on GitHub, why can’t I open PR here like I would do for every other project on GitHub).

[...]

OpenStack does its best in the org and repo descriptions on GitHub to highlight that they're convenience mirrors, and to point to the community's accepted workflows. Does that get overlooked? Is there something better that could be done to make it clear?

I doubt we can improve this. We mention in the project description it is mirror, but that is too easy to overlook. Otherwise every readme should start with bold statement: "do not open PRs here"

...

[...]

I think supporting multiple commit workflows and code review tools within the OpenDev Collaboratory would be even more confusing and add further conceptual barrier (what do you mean to commit to OpenStackSDK I need to use a different set of tools and review process than gophercloud, even though they're both in OpenDev?).

But from a technical feasibility standpoint, it's also more than just the lack of a Gitea driver for Zuul: our current Gitea server farm is read-only for technical reasons including lack of support in Gitea for a shared writeable storage backend, the fact that we would need to set up separate authentication/account management (we still need help from more people to make progress on our Keycloak SSO deployment), not to mention it would effectively double the security risk profile.

Thanks for adding more technical infos here, it was just an idea.

...

I agree we need to support making landscape flexible. But I am not 100% sure we should currently (due to general lack of contributions) simply refuse those willing to contribute into OpenStack . Terraform is a very prominent example here as well - you must be on GitHub to publish your artefacts. Don’t we want to have official TF provider following our best practices (therefore this is not an infrastructure only question)?

[...]

Is a source code mirror on GitHub not sufficiently "on GitHub" from Terraform's perspective?

Should be sufficient

...

we may explore publishing to GitHub mirror releases while still doing development on gitea. That requires having GH app token though (that is actually where those Vault plugins are being useful - you just fetch the token from vault and it expires afterwards).

[...]

OpenStack's GitHub mirroring relies on a Zuul job with account credentials for the openstack org encoded as a secret in the job definition, and other projects do similarly for mirrors to their respective orgs as well. Performing other API interactions in jobs is similarly possible, so telling GitHub to make a "release" of something there would probably be a trivial addition.

Absolutely sufficient. Basically they refer on the webhook that gets triggered on pushing new “release”. But that is just one example of things requiring something different to how we work.

...

I would rather disagree with such statement: just because you host your code on a proprietary hosting (but make it freely available) does not mean your are violating this mission. I also believe we should be using open source tools (and we do that), but that doesn’t mean everyone else is breaking bad [not meant to be abusive statement].

You're spending your valuable time producing open source software, so you must see some value in your choice to make it open source and would rather users picked it over proprietary alternatives. I personally would feel rather hypocritical were I to claim that open source development is a good thing when it's the software I'm creating, but that I don't find the open source alternatives to proprietary code hosting and development tools similarly valuable and would rather choose what's convenient or popular instead. How can I expect the communities producing those tools to make traction against proprietary platforms if I choose to be part of that problem

For me the problem here is not whether GitHub is open source or not. Surely there are open source solutions, but that require company to actually run this hosting. You can try to to go opendev to do development there, but here you pay with gerrit.

rather than part of the solution? I feel similarly disheartened when I attend an open source software conference and see someone give a presentation extolling the virtues of these practices, while clearly running their slide deck from MacOS or Windows.

My company gives me laptop (and actually there are valid reasons for running some form of Enterprise stuff there). I have honestly no freedom in what I use to run slide decks. I would really love to have a purely Linux laptop, but I can’t. However I do my best to use open source tools to create my slide decks.

On the other side you mentioned gitea is lacking support for required piece and that is exactly the case where you eventually can’t chase open source anymore. We can try, but I doubt we are able to reimplement so many things in the purely open source style. I guess not even any car now runs with a purely open source firmware. Would you not use it because of that?

...

Generally we have again here the same “infra” concerns in the discussion (which are already known historically, but anyway thanks for making them clear again), but what about other opinions? Are there any other thoughts or am I the only one interested to get this sorted out?

If I can try to restate your request, it seems like you want to develop software using some different tool choices than those available in the OpenDev Collaboratory. All the software we run in OpenDev (and all the software we use to develop and maintain the services and deployment in OpenDev) is 100% open source, along with its configuration. If you want to run a different combination of those services for your community while reusing some of OpenDev's solutions, you absolutely can do that and a number of people do so already.

I know it is possible, but we didn’t proceed this way (most likely due to your statement in http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025663....)

...

Just to repeat, my current case is really about a very strong desire and, I would say even need, to have gophercloud be very close to OpenStackSDK. Can we at least think about placing them under OpenStack GitHub org without Zuul access to have a better affiliation with OpenStack (gopher folks, hope you do not mind of such step. Or maybe we try to demonstrate here how to make this manageable with Zuul - reach me out if there is interest)?

[...]

I'm probably still misunderstanding what you mean by "very close to" in this statement. If the most important aspect of this is that gophercloud appears in the openstack org on GitHub, but you don't wish to actually use the development methodology and code review workflow of the OpenStack community, then that doesn't seem close at all. But maybe you mean "close" from a marketing perspective? Mirrors to GitHub are not something OpenDev sysadmins really even get involved with, it's just automation individual projects implement and maintain for themselves, so it's the OpenStack TC's choice as to what projects they'll allow to appear in their GitHub org, and really nothing to do with the OpenDev Collaboratory itself.

And one thing I still don't feel like you've covered is your earlier assertion that gophercloud project leadership was told the OpenInfra Foundation refused to legally represent them unless they hosted their development in the OpenDev Collaboratory. As I mentioned in my earlier reply, there are already OpenInfra projects which do all their software development in GitHub and run their own CI systems completely separate from OpenDev, so I really doubt you've been given an accurate account of what was discussed between foundation leadership and gophercloud folks. It would probably be good to seek further clarification there.

Maybe right. Afaik (at least what I followed) the discussion got stuck on a statement that the folks must move to opendev to achieve that and they could not agree on that due to fear of loosing contributors). I have only http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025884.... http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025884.html as last message to refer to.

My ultimate goal (“very close”) would be to have gophercloud on opendev and be a delivery of SDK team so that we can use same tooling and standards to test them. If being located on opendev is not an option I would love to have it on ANY git hosting with opendev Zuul integration to still be able to use same tooling to test them. If this ANY hosting is GitHub I would prefer to see it under OpenStack organisation from marketing perspective. Same would be valid for terraform provider for OpenStack, especially from marketing point of view, but I do not really know whether its maintainers are having an interest in that at all. At the moment those 2 examples are affiliated with OpenStack, but they feel so much detached from OpenStack development, that it does not really look proper to me. Since we may talk generally about "OpenStack affiliated" products of course there might be some limitations.

I learned openlab got problems, so gopher and TF are not even able to run Zuul jobs anymore. So unless somebody offers Zuul they can’t even do proper gating.

Artem

On 2022-06-22 16:38:24 +0200 (+0200), Artem Goncharov wrote: [...]

For me the problem here is not whether GitHub is open source or not. Surely there are open source solutions, but that require company to actually run this hosting. You can try to to go opendev to do development there, but here you pay with gerrit.

[...]

OpenDev is not the only community-run code hosting service based on open source software. There are quite a few others to choose from, some of which are based on systems which employ a pull request or merge request workflow. But yes, it's easier to not look for them that's it's not a priority for you to begin with.

My company gives me laptop (and actually there are valid reasons for running some form of Enterprise stuff there). I have honestly no freedom in what I use to run slide decks. I would really love to have a purely Linux laptop, but I can’t. However I do my best to use open source tools to create my slide decks.

But we do have some choice in who we work for. As someone who has pressed my employers to use open source software since the 1990s, and sometimes even defied them in order to avoid compromising my ideals, I do get that it's not easy at times. For some, working on open source software is "just a job" and not an integral part of their life or ideology. That's perfectly okay. In fact, I still find it pretty amazing that it's become so normalized for people to get paid from working on open source projects to the extent that it can be "just a job" rather than an ideology now.

On the other side you mentioned gitea is lacking support for required piece and that is exactly the case where you eventually can’t chase open source anymore. We can try, but I doubt we are able to reimplement so many things in the purely open source style. I guess not even any car now runs with a purely open source firmware. Would you not use it because of that?

This feels like a defeatist attitude, and one that I thankfully don't share. Yes the places where proprietary software still has market share are many and can seem like daunting mountains to try to scale. I take it as a challenge, prioritizing systems with open source firmware, based on open design boards and open specification chipsets for as many of my hardware purchases as possible. I get involved in those communities, and I make sure anything I build is made freely available under open community licenses. It's a lot of effort, and it's not for everyone sure, but please don't be so quick to dismiss the passions of others to solve this problem even if you think it's futile.

I know it is possible, but we didn’t proceed this way (most likely due to your statement in http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025663....)

Nowhere in there did I tell you not to use GitHub and not to run your own CI system. I explained that OpenDev doesn't gate GitHub projects with the Zuul instance it runs, and the reasons why we don't. It might be a reason for you not to use OpenDev, but it shouldn't have a bearing on whether you make different choices for the services you run for your community.

Maybe right. Afaik (at least what I followed) the discussion got stuck on a statement that the folks must move to opendev to achieve that and they could not agree on that due to fear of loosing contributors). I have only http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025884.... as last message to refer to.

I think you're probably conflating "part of OpenStack" with legal representation by the OpenInfra Foundation. OpenStack is an official OpenInfra project, but it is not the only official OpenInfra project. OpenStack does use OpenDev for its development practices at present, but not all OpenInfra projects do so.

My ultimate goal (“very close”) would be to have gophercloud on opendev and be a delivery of SDK team so that we can use same tooling and standards to test them.

The fact that OpenStack relies heavily on a Gerrit-based code review process is part of those "tooling and standards." I'm still not grasping how using something other than the services OpenDev provides is still "on opendev" but it's likely you have a very different definition for what that means than I do.

If being located on opendev is not an option I would love to have it on ANY git hosting with opendev Zuul integration to still be able to use same tooling to test them.

As already mentioned, OpenDev's Zuul does already connect to public GitHub in order to serve as a third-party CI and auxiliary build service for projects which are dependencies of projects in OpenDev's Gerrit. If OpenStackSDK wants to run tests which consume pull requests for gophercloud and report back to GitHub with results, that's quite easy to add. Where we draw the line is that we won't consume Zuul configuration from projects which aren't hosted in our Gerrit, and we won't gate projects hosted outside our Gerrit.

If this ANY hosting is GitHub I would prefer to see it under OpenStack organisation from marketing perspective. Same would be valid for terraform provider for OpenStack, especially from marketing point of view, but I do not really know whether its maintainers are having an interest in that at all.

This is entirely up to the OpenStack TC, so I have no opinion on it one way or the other. Part of the formation of the OpenDev Collaboratory was removing the direct GitHub integration we were running in service of OpenStack, and handing over control of that organization to people in the OpenStack community who see some value in having a presence on GitHub and were willing to maintain new integration with it themselves.

At the moment those 2 examples are affiliated with OpenStack, but they feel so much detached from OpenStack development, that it does not really look proper to me. Since we may talk generally about "OpenStack affiliated" products of course there might be some limitations.

Not following the same code review workflows as OpenStack makes them feel very detached from OpenStack development. Simply moving them into the openstack org on GitHub won't change that.

I learned openlab got problems, so gopher and TF are not even able to run Zuul jobs anymore. So unless somebody offers Zuul they can’t even do proper gating.

While I can't guarantee they'll be willing, VEXXHOST runs managed Zuul services for other open source communities, so might be willing to entertain a request to do so for gophercloud and Terraform:

https://vexxhost.com/solutions/managed-zuul/

Similarly, Software Factory hosts a bunch of open source projects and provides Zuul tenants for them:

https://softwarefactory-project.io/

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

[1] https://github.com/sqlalchemy/sqlalchemy/pull/7964

On 2022-06-23 10:02:14 -0500 (-0500), Ghanshyam Mann wrote: [...]

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.

[...]

"Governance" (the new project requirements document) right now clearly states that new projects need to perform their code review and gating tests on the "OpenStack Infrastructure" (the former name for the OpenDev Collaboratory because that document hasn't been updated to reflect the new name). You'll at a minimum need a vote of the TC to remove those restrictions, so all this assumes that the rest of the TC agrees with you that doing code review in GitHub with a separate GitHub-connected CI system is allowable for new official OpenStack project teams and deliverables.

This is not "governance point of view" it's *your* point of view, so please be clear that the decision is one the TC as a whole will need to make.

On 2022-06-23 12:13:50 -0500 (-0500), Ghanshyam Mann wrote:

---- On Thu, 23 Jun 2022 10:30:24 -0500 Jeremy Stanley fungi@yuggoth.org wrote ----

...

On 2022-06-23 10:02:14 -0500 (-0500), Ghanshyam Mann wrote: [...]

...

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.

[...]

"Governance" (the new project requirements document) right now clearly states that new projects need to perform their code review and gating tests on the "OpenStack Infrastructure" (the former name for the OpenDev Collaboratory because that document hasn't been updated to reflect the new name). You'll at a minimum need a vote of the TC to remove those restrictions, so all this assumes that the rest of the TC agrees with you that doing code review in GitHub with a separate GitHub-connected CI system is allowable for new official OpenStack project teams and deliverables.

This is not "governance point of view" it's *your* point of view, so please be clear that the decision is one the TC as a whole will need to make.

I think there is some misunderstanding here. I have never said anywhere that this is "TC agreed view" off-course this is my opinion as a community member as well as TC member.

Any community member or TC members can provide their opinion but that should not be considered as "TC agreed plan" until that is explicitly mentioned in email or TC pass the resolution. We can have different views from TC members or chair but any of that should not be considered as "TC agreement" unless mentioned. I think this is how every email discussion is.

You referred to it above as the "governance point of view" so I just wanted to make certain you don't actually believe the governing documents are unclear on this particular point, and understand that OpenStack absolutely will need TC consensus on lifting a longstanding restriction in order to allow an official deliverable to be hosted outside the "OpenStack Infrastructure" (a.k.a. OpenDev Collaboratory).

I have this in my list to give a clear picture from TC as an agreed plan:

Step1: Continue the discussion in ML (here) Step2: After having a good amount of feedback here and we still not resolved the things, I will add this topic to TC meeting and get the TC consensus. Step3: Propose Governance resolution or documentation update Step4: Update the same in ML as "TC agreed plan".

Thanks, this looks like a reasonable way forward.

On Thu, Jun 23, 2022 at 12:55 PM Jeremy Stanley fungi@yuggoth.org wrote:

On 2022-06-23 12:13:50 -0500 (-0500), Ghanshyam Mann wrote:

...

---- On Thu, 23 Jun 2022 10:30:24 -0500 Jeremy Stanley <

fungi@yuggoth.org> wrote ----

...

...

On 2022-06-23 10:02:14 -0500 (-0500), Ghanshyam Mann wrote: [...]

...

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.

[...]

"Governance" (the new project requirements document) right now clearly states that new projects need to perform their code review and gating tests on the "OpenStack Infrastructure" (the former name for the OpenDev Collaboratory because that document hasn't been updated to reflect the new name). You'll at a minimum need a vote of the TC to remove those restrictions, so all this assumes that the rest of the TC agrees with you that doing code review in GitHub with a separate GitHub-connected CI system is allowable for new official OpenStack project teams and deliverables.

This is not "governance point of view" it's *your* point of view, so please be clear that the decision is one the TC as a whole will need to make.

I think there is some misunderstanding here. I have never said anywhere that this is "TC agreed view" off-course this is my opinion as a community member as well as TC member.

Any community member or TC members can provide their opinion but that should not be considered as "TC agreed plan" until that is explicitly mentioned in email or TC pass the resolution. We can have different views from TC members or chair but any of that should not be considered as "TC agreement" unless mentioned. I think this is how every email discussion is.

You referred to it above as the "governance point of view" so I just wanted to make certain you don't actually believe the governing documents are unclear on this particular point, and understand that OpenStack absolutely will need TC consensus on lifting a longstanding restriction in order to allow an official deliverable to be hosted outside the "OpenStack Infrastructure" (a.k.a. OpenDev Collaboratory).

As a TC member, I do not think that any project that is a part of OpenStack should be hosted outside OpenDev. To be a part of OpenStack, you have to be hosted in OpenDev. I think that splitting to use Github + OpenDev will create too much complexity for new contributors in addition to everything else already mentioned about CI and release management further up in this thread.

...

I have this in my list to give a clear picture from TC as an agreed plan:

Step1: Continue the discussion in ML (here) Step2: After having a good amount of feedback here and we still not resolved the things, I will add this topic to TC meeting and get the TC consensus. Step3: Propose Governance resolution or documentation update Step4: Update the same in ML as "TC agreed plan".

Thanks, this looks like a reasonable way forward.

Documents should definitely get updated! +2!

On Thu, Jun 23, 2022 at 7:43 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:

---- On Thu, 23 Jun 2022 15:02:57 -0500 Kendall Nelson < kennelson11@gmail.com> wrote ----

...

On Thu, Jun 23, 2022 at 12:55 PM Jeremy Stanley fungi@yuggoth.org

wrote:

...

On 2022-06-23 12:13:50 -0500 (-0500), Ghanshyam Mann wrote:

...

---- On Thu, 23 Jun 2022 10:30:24 -0500 Jeremy Stanley <

fungi@yuggoth.org> wrote ----

...

...

...

On 2022-06-23 10:02:14 -0500 (-0500), Ghanshyam Mann wrote: [...]

...

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.

[...]

"Governance" (the new project requirements document) right now clearly states that new projects need to perform their code review and gating tests on the "OpenStack Infrastructure" (the former name for the OpenDev Collaboratory because that document hasn't been updated to reflect the new name). You'll at a minimum need a vote

of

...

...

...

the TC to remove those restrictions, so all this assumes that the rest of the TC agrees with you that doing code review in GitHub

with

...

...

...

a separate GitHub-connected CI system is allowable for new official OpenStack project teams and deliverables.

This is not "governance point of view" it's *your* point of view,

so

...

...

...

please be clear that the decision is one the TC as a whole will

need

...

...

...

to make.

I think there is some misunderstanding here. I have never said anywhere that this is "TC agreed view" off-course this is my opinion as a community member as well as TC member.

Any community member or TC members can provide their opinion but that should not be considered as "TC agreed plan" until that is explicitly mentioned in email or TC pass the resolution. We can have different views from TC members or chair but any of that should not be considered as "TC agreement" unless mentioned. I think this is how every email discussion is.

You referred to it above as the "governance point of view" so I just wanted to make certain you don't actually believe the governing documents are unclear on this particular point, and understand that OpenStack absolutely will need TC consensus on lifting a longstanding restriction in order to allow an official deliverable to be hosted outside the "OpenStack Infrastructure" (a.k.a. OpenDev Collaboratory).

As a TC member, I do not think that any project that is a part of

OpenStack should be hosted outside OpenDev. To be a part of OpenStack, you have to be hosted in OpenDev. I think that splitting to use Github + OpenDev will create too much complexity for new contributors in addition to everything else already mentioned about CI and release management further up in this thread.

Well, I am not sure how valid the new contributors criteria is nowadays because we hardly get any new contributors in any of the OpenStack project. But here we are denying the interested contributors to contribute their project to OpenStack because of the tooling they want to use in developing their code. I am not sure if we will get other new contributors in gophercloud if it is hosted on opendev.

I feel like that is kind of a defeatist attitude- that we shouldn't keep new contributors to OpenStack in mind. There are new people coming in every round of outreachy, every semester at NDSU, BU, Northwestern... I am in contact with 3 more universities since the Berlin summit looking to form similar relationships with us. That's not nothing?

If the process of getting started becomes more complex, I think we will struggle even more to get new people involved and build them into the next generation of contributors to step up when the current folks have to/ want to move on. Many projects already have a very short bench and I can only see fracturing our development processes as making it harder to build up the number of contributors we have to support our teams and those that have been in leadership roles so long they are looking to step down soon.

-gmann

...

...

I have this in my list to give a clear picture from TC as an agreed plan:

Step1: Continue the discussion in ML (here) Step2: After having a good amount of feedback here and we still not resolved the things, I will add this topic to TC meeting and get the TC consensus. Step3: Propose Governance resolution or documentation update Step4: Update the same in ML as "TC agreed plan".

Thanks, this looks like a reasonable way forward.

Documents should definitely get updated! +2!

Jeremy Stanley

-Kendall Nelson

-Kendall Nelson

On 2022-06-24 20:01:09 +0200 (+0200), Artem Goncharov wrote: [...]

• can we have official OpenStack projects outside opendev? [yes/no]
• can we have non-official OpenStack projects (lets call them affiliated) not hosted on opendev under *some* OpenStack governance? [yes/no]
• can we have OpenStack manage *git* organisation (i.e. GitHub organisation) as well as artifacts publishing for those outside of opendev as some form of limited governance? This may or may not include some more regulations regarding PTI, code-review, etc. Purpose is to improve marketing side of the delivery and be able to revive it once current maintainers depart [yes/no]

Those are up to the TC members to decide, so I'll leave that to them.

• can we provide Zuul gating for those official or affiliated projects outside of opendev (with strict regulations what and how)? [yes/no]

If that's a question for the OpenDev sysadmins, we've got a pretty firm collective "no" on it at this point based on prior discussions. We're happy for projects to set up advisory testing for dependencies hosted on GitHub (think "third-party CI" type feedback on those projects' pull requests) and do things like provide builds of ARM/AArch64 wheels for pyca/cryptography in order to make OpenStack's ARM-based jobs much faster, but configuring our Zuul deployment to provide gating services for projects hosted outside the Gerrit we operate isn't happening in my opinion.

• can we _think_ on allowing people use alternative public auth

providers (i.e. GitHub, ...) accounts with OpenStack to lower the entry barrier? [yes/no]

[...]

That's one of the goals for https://docs.opendev.org/opendev/infra-specs/latest/specs/central-auth.html so if you have time or know someone who has time to help make further progress on it, please let us know. We have a Keycloak PoC already up so we can demo authenticating Zuul admin API calls (at https://keycloak.opendev.org/ currently), but the larger effort is migration planning and integrating the existing Launchpad OpenID as a source so we can let existing users continue to authenticate, at least temporarily.

---- On Fri, 24 Jun 2022 13:39:12 -0500 Ghanshyam Mann gmann@ghanshyammann.com wrote ---

---- On Fri, 24 Jun 2022 11:44:27 -0500 Kendall Nelson kennelson11@gmail.com wrote ---

...

On Thu, Jun 23, 2022 at 7:43 PM Ghanshyam Mann gmann@ghanshyammann.com wrote: ---- On Thu, 23 Jun 2022 15:02:57 -0500 Kendall Nelson kennelson11@gmail.com wrote ----

...

On Thu, Jun 23, 2022 at 12:55 PM Jeremy Stanley fungi@yuggoth.org wrote: On 2022-06-23 12:13:50 -0500 (-0500), Ghanshyam Mann wrote:

...

---- On Thu, 23 Jun 2022 10:30:24 -0500 Jeremy Stanley fungi@yuggoth.org wrote ----

...

On 2022-06-23 10:02:14 -0500 (-0500), Ghanshyam Mann wrote: [...]

...

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.

[...]

"Governance" (the new project requirements document) right now clearly states that new projects need to perform their code review and gating tests on the "OpenStack Infrastructure" (the former name for the OpenDev Collaboratory because that document hasn't been updated to reflect the new name). You'll at a minimum need a vote of the TC to remove those restrictions, so all this assumes that the rest of the TC agrees with you that doing code review in GitHub with a separate GitHub-connected CI system is allowable for new official OpenStack project teams and deliverables.

This is not "governance point of view" it's *your* point of view, so please be clear that the decision is one the TC as a whole will need to make.

I think there is some misunderstanding here. I have never said anywhere that this is "TC agreed view" off-course this is my opinion as a community member as well as TC member.

Any community member or TC members can provide their opinion but that should not be considered as "TC agreed plan" until that is explicitly mentioned in email or TC pass the resolution. We can have different views from TC members or chair but any of that should not be considered as "TC agreement" unless mentioned. I think this is how every email discussion is.

You referred to it above as the "governance point of view" so I just wanted to make certain you don't actually believe the governing documents are unclear on this particular point, and understand that OpenStack absolutely will need TC consensus on lifting a longstanding restriction in order to allow an official deliverable to be hosted outside the "OpenStack Infrastructure" (a.k.a. OpenDev Collaboratory).

As a TC member, I do not think that any project that is a part of OpenStack should be hosted outside OpenDev. To be a part of OpenStack, you have to be hosted in OpenDev. I think that splitting to use Github + OpenDev will create too much complexity for new contributors in addition to everything else already mentioned about CI and release management further up in this thread.

Well, I am not sure how valid the new contributors criteria is nowadays because we hardly get any new contributors in any of the OpenStack project. But here we are denying the interested contributors to contribute their project to OpenStack because of the tooling they want to use in developing their code. I am not sure if we will get other new contributors in gophercloud if it is hosted on opendev.

I feel like that is kind of a defeatist attitude- that we shouldn't keep new contributors to OpenStack in mind. There are new peoplecoming in every round of outreachy, every semester at NDSU, BU, Northwestern... I am in contact with 3 more universities since the Berlin summit looking to form similar relationships with us. That's not nothing? If the process of getting started becomes more complex, I think we will struggle even more to get new people involved and buildthem into the next generation of contributors to step up when the current folks have to/ want to move on. Many projects already have a very short bench and I can only see fracturing our development processes as making it harder to build up the number ofcontributors we have to support our teams and those that have been in leadership roles so long they are looking to step down soon.

No, it's not a defeatist attitude but instead a practical attitude and move forward to progress the things rather than stuck on currently-not-working stuff. Being practical based on facts and not being optimistic is not defeat.

I think Artem also explained it what I meant by 'new contributor' in this context. But let me elaborate on my statement. There are two different sets of new contributors 1. short-term: outreach, intern or so 2. Long-term. I am talking about the 2nd one here as 1st one is anyways going after a short time and it is the same for them to learn Gerrit or GitHub. Long-term new contributors are someone we need to think that our process/tooling are ok for them to sustain as long term or it is too complex/split to work. For example: "Hey, my company is asking me to be a new long-term maintainer in OpenStack but I deny it because OpenStack uses more than one set of tooling to develop the code or run the tests". In this example, before saying more than one tooling will be difficult for new contributors we should answer two very practical questions:

1. How many of such new contributors do we have in OpenStack
2. If there is, do they need to learn two processes? I think they will be contributing to a single project following a single

process/tool. If we get some super contributor to all projects then it is a different thing.

And practical data is "we do not get new contributors helping us with help needed things", Below points can justify it:

1. no help on our help needed (upstream investment opportunity) list "because of fewer contributors".
2. Many projects get retired in every cycle "because of fewer contributors".
3. OpenStack Infra (OpenDev) is shrinking, many services are shutting down "because of fewer contributors".
4. OpenStack Community is not able to finish user-facing features like RBAC, OSC on time "because of fewer contributors".
5. Most of our existing contributors are overloaded and slowly burnout "because of fewer contributors". OpenDev maintainer

overloaded is a good example. 6. OpenStack supporting teams like QA, infra, requirement, stable branch, and releases do not have enough maintainers that they require.

I am saying what strategy or program will work to fix these but in the current situation, we have to accept that these are problems because we do not get new contributors. If we cannot fix them then we have to adjust ourself as per current situation even change the things which previously agreed or worked.

I am starting another discussion here to fix this new contributor problem in this thread but I am saying that considering the new contributors criteria in this email thread context and not changing the things is not relevant,

* I am *not* starting another discussion here to fix.....

-gmann

-gmann

...

-gmann

...

...

I have this in my list to give a clear picture from TC as an agreed plan:

Step1: Continue the discussion in ML (here) Step2: After having a good amount of feedback here and we still not resolved the things, I will add this topic to TC meeting and get the TC consensus. Step3: Propose Governance resolution or documentation update Step4: Update the same in ML as "TC agreed plan".

Thanks, this looks like a reasonable way forward.

Documents should definitely get updated! +2!

Jeremy Stanley

-Kendall Nelson

-Kendall Nelson

---- On Fri, 24 Jun 2022 15:09:38 -0500 Clark Boylan cboylan@sapwetik.org wrote ---

On Fri, Jun 24, 2022, at 11:39 AM, Ghanshyam Mann wrote:

...

snip

...

No, it's not a defeatist attitude but instead a practical attitude and move forward to progress the things rather than stuck on currently-not-working stuff. Being practical based on facts and not being optimistic is not defeat.

I think Artem also explained it what I meant by 'new contributor' in this context. But let me elaborate on my statement. There are two different sets of new contributors 1. short-term: outreach, intern or so 2. Long-term. I am talking about the 2nd one here as 1st one is anyways going after a short time and it is the same for them to learn Gerrit or GitHub. Long-term new contributors are someone we need to think that our process/tooling are ok for them to sustain as long term or it is too complex/split to work. For example: "Hey, my company is asking me to be a new long-term maintainer in OpenStack but I deny it because OpenStack uses more than one set of tooling to develop the code or run the tests". In this example, before saying more than one tooling will be difficult for new contributors we should answer two very practical questions:

1. How many of such new contributors do we have in OpenStack
2. If there is, do they need to learn two processes? I think they will

be contributing to a single project following a single process/tool. If we get some super contributor to all projects then it is a different thing.

And practical data is "we do not get new contributors helping us with help needed things", Below points can justify it:

1. no help on our help needed (upstream investment opportunity) list

"because of fewer contributors". 2. Many projects get retired in every cycle "because of fewer contributors". 3. OpenStack Infra (OpenDev) is shrinking, many services are shutting down "because of fewer contributors". 4. OpenStack Community is not able to finish user-facing features like RBAC, OSC on time "because of fewer contributors". 5. Most of our existing contributors are overloaded and slowly burnout "because of fewer contributors". OpenDev maintainer overloaded is a good example. 6. OpenStack supporting teams like QA, infra, requirement, stable branch, and releases do not have enough maintainers that they require.

I am saying what strategy or program will work to fix these but in the current situation, we have to accept that these are problems because we do not get new contributors. If we cannot fix them then we have to adjust ourself as per current situation even change the things which previously agreed or worked.

I am starting another discussion here to fix this new contributor problem in this thread but I am saying that considering the new contributors criteria in this email thread context and not changing the things is not relevant,

While you didn't want to start a new conversation on this topic, I do think it is worthwhile to consider why we think this might help anything if that is the argument being made to justify these potential actions.

I think there are two main angles to look at this.

The first is does this reduce the burden on us? Potentially if you replaced self hosted services with services hosted by others that could be the case. This isn't risk free (think what happened with transifex or docker hub), but the risk may be worth the return. As mentioned elsewhere in the thread if we want to continue to uphold our community values it would be better to consider hosted open source options instead. You also have to accept the limitations of whatever the new platform is, because if you start doing a bunch of custom work around it you're back where you started and haven't reduced much burden.

The other is whether or not we're likely to infuse new blood by making a change. This is where things get a lot more murky for me. I don't think it is universally true that choosing to use github is going to magically create new contributors. You only have to look at gnocchi to see a historical example of this. Our projects need maintainers. Maintenance of software requires some non trivial involvement. You might get a few more drive by contributions, but that will only help the projects grow long term if you can convert some subset to maintainers. This is difficult. This is difficult regardless of the platform you choose to develop on.

I think that if the goal is attracting new contributors we should be explicit about why the actions we are taking are believed to help with that not just simply assert that it is the case.

Also, adding a new project like gophercloud won't automatically add contributors to openstack. Contributors to gophercloud will continue to be contributors to gophercloud. In fact you point out above it is unlikely they will contribute to other projects. For this reason I think it is also worthwhile to think about what benefits of such a change exist. Does openstack benefit in any way by adding gophercloud to openstack but not changing anything about their contribution methods? Does gophercloud benefit in any way? To me this is essentially the status quo only with new additional governance overhead.

Exactly, that is what I was trying to make this point. Having 'new contributors' are very fewer chances nowadays even if we stick to single tooling of more than one.

gophercloud in OpenStack or outside, on OpenDev or Github, separate governance project or within any of the OpenInfra projects, none of these factors will make any difference in getting or not getting the "new contributors" in OpenStack That is why I am saying let's not have these 'new contributors' point to decide the gophercloud cloud request to be in different tooling.

-gmann

On Fri, Jun 24, 2022, at 1:36 PM, Artem Goncharov wrote:

...

Also, adding a new project like gophercloud won't automatically add contributors to openstack. Contributors to gophercloud will continue to be contributors to gophercloud. In fact you point out above it is unlikely they will contribute to other projects. For this reason I think it is also worthwhile to think about what benefits of such a change exist. Does openstack benefit in any way by adding gophercloud to openstack but not changing anything about their contribution methods? Does gophercloud benefit in any way? To me this is essentially the status quo only with new additional governance overhead.

Ugh, if gophercloud is not helping OpenStack we can forget about letting users run k8 on Openstack, Openshift on OpenStack, we can say Ansible and OSC are not helping OpenStack, because this is the same vector of tooling: it's not OpenStack services, but ecosystem around OpenStack. We even had a keynote on that during summit.

There are users ready to submit small fixes to the tooling they use daily. But nobody of them is willing to go through our current contribution requirements, they just abandon this and stay dissatisfied. Users are not even able to do easy bug reporting since also for that they need to learn new and very uncomfortable tools. This is not user friendly from my pov.

The point I was trying to make was more that nothing stops that contribution from happening today on Github if that is where those individuals prefer to be. What changes if the repo moves under the Github openstack organization and we formally add the project to openstack governance? There are some changes for sure, but most aren't going to be visible/important to those individuals.

I'm trying to get us to be explicit about the benefits and cross check them against our goals. I'm not necessarily saying it is a bad idea. It may be that those people want to vote in TC elections and have a greater say in the direction of openstack as a whole. If that is the case let's say that and make sure that benefits like that align with any goals of such a move.

I'm not saying that contributions like that don't benefit the ecosystem. I'm specifically trying to understand what benefits to this specific change there are to both parties. It isn't clear to me if part of the move is explicitly ignoring the way openstack has chosen to do things.

On Mon, 2022-06-27 at 11:39 +0200, Artem Goncharov wrote:

...

...

The point I was trying to make was more that nothing stops that contribution from happening today on Github if that is where those individuals prefer to be. What changes if the repo moves under the Github openstack organization and we formally add the project to openstack governance? There are some changes for sure, but most aren't going to be visible/important to those individuals.

I'm trying to get us to be explicit about the benefits and cross check them against our goals. I'm not necessarily saying it is a bad idea. It may be that those people want to vote in TC elections and have a greater say in the direction of openstack as a whole. If that is the case let's say that and make sure that benefits like that align with any goals of such a move.

I'm not saying that contributions like that don't benefit the ecosystem. I'm specifically trying to understand what benefits to this specific change there are to both parties. It isn't clear to me if part of the move is explicitly ignoring the way openstack has chosen to do things.

Let me give here couple of examples:

• When I am doing some bigger changes in SDK/OSC/Ansible it is logical to have a devstack running locally to be able to try it out and somehow

ensure tests will work without burning CI in endless patchsets due to typos and other type of bugs. Chances that I will be able just to start devstack on my laptop and it immediately works are terribly low. I am not going to go into details why, this is not relevant here. Due to this in most cases, unless I do something much bigger and ready to invest eventually 1-2 hour to get devstack running I skip this and go into the blind flight relying only on CI. And as mentioned earlier producing sometimes lot of patchsets.

• My contributions to Zuul are actually facing very similar challenge. I am able to reverse engineer how to be able to run tests locally, but

honestly this is not something I really want to do, especially in a fast evolving software. Due to that for fixing one bug I am spending 20 patchsets and weeks of time (everybody here know perfectly how much time we usually wait for CI results and endless rechecks). With that I honestly think twice, do I have enough “free time” and commitement to try fix the bug properly or I have a workaround I can apply in my installation

• I have seen from other teams, but now talking explicitly about myself: using storyboard is so inconvenient that I just stopped using it (neither

for reporting myself, nor looking what others report to my projects). I even see often people reusing some external issue trackers just to make it somehow usable (I am waiting so desperately for us finally enabling gitea issues)

i dont like storyboard but i have no issue with using launch pad as it currently stands. it does what we need of it for bug/feature tracking . i dont really object to evaluating gitia issue if they were avaiable but i dont think there is a stong need to change form launch pad in general. its certenly preferable to the mix of bugzilla,jria and trello i also have to deal with but i woudl hope that if we were to use gitia issues we woudl consolidate and not have 3 solution upstream.

keepign track of where we keep track of things upstream and downstream is already a full time job so adding more options is an increased burden so i woudl hope we could consolidate.

• Very often when somebody is asking me about particular place in code they (and this is often valid for the referred super contributors) share link

to GitHub and not opendev.

What I am trying to say with that is that there are convenience factors we should not neglect. Once developer feels not comfortable with the contribution workflow he/she will not do this at all, unless he/she is a long-time committed contributor. Users willing to report issue in OSC/SDK/Ansible area often give up on that after seeing what they need to do in order to at least report the issue. I give up on tracking what users report to the projects I am responsible for in an official way. The ones willing to contribute a small fix give up after seeing their PR is auto closed. This is not about: we are bad. This is about if developer doesn’t feel comfortable in the work we will not win him for us. This is something I learn through pain during last 10 years or so.

ther eare some convince factors to github and many inconvenices., it has a vastly inferior code review model that if i was force to use would push me out of the openstack comunity long term. im sure there are others too that feel stongly that moving to a github pull request based workflow woudl be a large regerssion and make them less inclined to continue working on openstack.

I am very glad to hear that proper SSO is moving closer. Also awesome to hear we may be close to get issues feature of gitea. Those are the things that should make daily life a tick easier and we may really improve this.

Artem

On Mon, 2022-06-27 at 15:30 +0200, Artem Goncharov wrote:

...

ther eare some convince factors to github and many inconvenices., it has a vastly inferior code review model that if i was force to use would push me out of the openstack comunity long term. im sure there are others too that feel stongly that moving to a github pull request based workflow woudl be a large regerssion and make them less inclined to continue working on openstack.

The thread is being very explicit about external projects and not the OpenStack itself.

yep but that is unhelpful. if any external project that work with openstack want to become part of openstack under the foundatiosn governace it is nolonger external.

so if gophercloud was to become part of openstack it would not be external and if it wanted to you github pull requests for it workflow it woudl be deviating form the other openstack projects.

external project that are not part of openstack governacne can use any tooling they like.

if we start allowing arbiatry internal and external project to use gerrit or github workflows of worse both concurrently we will start getting request to supprot that for other proejct like nova neutron ectra. i woudl see that as damaging to the exsting colaberator based and something to be avoided if we can.

im not really sure what gophercloud want to achive by being part of openstack without adopting the openstack ways of doing things that they cant acive by bing a nice go sdk for openstack on there own with the well wishes and or support of the openstack comunity.

the 4 opens are a core part of the culture of openstack simiarly the ways of workign with irc/gerrit/zuul/ptgs are also a part of the openstack way.

i am wondering why gophercloud want to actully becoem an offial proejct if they dont want to adopt the open developement workflow (note i did not say model) that openstack uses?

On Tue, 2022-06-28 at 09:12 -0400, Emilien Macchi wrote:

Sorry for the late reply, I'm still catching up e-mail backlog and plan to dig more in this thread at some point. I just wanted to answer Sean's question very simply. See inline below:

On Mon, Jun 27, 2022 at 9:59 AM Sean Mooney smooney@redhat.com wrote:

...

On Mon, 2022-06-27 at 15:30 +0200, Artem Goncharov wrote:

...

...

ther eare some convince factors to github and many inconvenices., it has a vastly inferior code review model that if i was force to use

would push me out of the openstack comunity long term.

...

...

im sure there are others too that feel stongly that moving to a github

pull request based workflow woudl be a large regerssion

...

...

and make them less inclined to continue working on openstack.

The thread is being very explicit about external projects and not the

OpenStack itself. yep but that is unhelpful. if any external project that work with openstack want to become part of openstack under the foundatiosn governace it is nolonger external.

so if gophercloud was to become part of openstack it would not be external and if it wanted to you github pull requests for it workflow it woudl be deviating form the other openstack projects.

external project that are not part of openstack governacne can use any tooling they like.

if we start allowing arbiatry internal and external project to use gerrit or github workflows of worse both concurrently we will start getting request to supprot that for other proejct like nova neutron ectra. i woudl see that as damaging to the exsting colaberator based and something to be avoided if we can.

im not really sure what gophercloud want to achive by being part of openstack without adopting the openstack ways of doing things that they cant acive by bing a nice go sdk for openstack on there own with the well wishes and or support of the openstack comunity.

the 4 opens are a core part of the culture of openstack simiarly the ways of workign with irc/gerrit/zuul/ptgs are also a part of the openstack way.

i am wondering why gophercloud want to actully becoem an offial proejct if they dont want to adopt the open developement workflow (note i did not say model) that openstack uses?

I'm a Gophercloud maintainer and can provide some context. Some of us at Red Hat inherited the project ( https://github.com/gophercloud/gophercloud/issues/2246) at the end of last year. The first thing we did was to check if the project could fit under the opendev umbrella as it seemed like the natural place to us. The discussion was run in the open: https://github.com/gophercloud/gophercloud/issues/2257 and http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025660.... The main reasons were:

• Gain more sustainability, contributors around the community and more

diversity in maintainers

• More stable CI (not relevant anymore since we moved to Github Actions,

and we do not rely on openlab anymore)

• CI integration in other projects
• Better governance

Thanks for that context.

with that in mind im not sure it makes sense to proceed with movign it under openstack governance.

i agree that it woudl be nice form a governance perspective to include it under the sdk team but if the opendev ways or workign dont work for the existing contibutor base im not sure it makes sense for ether comuntiy i do agree these ^ are good reasons to consider this change but im not conviced it woudl be good for openstack to add github hosting and review workflow.

When we asked the Gophercloud contributors about using gerrit, the feedback wasn't positive (details in #2257) so at this point we decided to not proceed further at the time. Due to the nature of the project, a lot of our pull-requests are "drive-by contributions" (e.g. to add new fields to the API) by new contributors; which ought to be considered if we were going to Gerrit.

That being said, if we get more contributions from the OpenStack community, this would certainly help to justify the move under opendev.

On Tue, Jun 28, 2022, 19:58 Ghanshyam Mann gmann@ghanshyammann.com wrote:

---- On Tue, 28 Jun 2022 08:44:22 -0500 Sean Mooney smooney@redhat.com wrote ---

...

On Tue, 2022-06-28 at 09:12 -0400, Emilien Macchi wrote:

...

Sorry for the late reply, I'm still catching up e-mail backlog and

plan to

...

...

dig more in this thread at some point. I just wanted to answer Sean's question very simply. See inline below:

On Mon, Jun 27, 2022 at 9:59 AM Sean Mooney smooney@redhat.com

wrote:

...

...

...

On Mon, 2022-06-27 at 15:30 +0200, Artem Goncharov wrote:

...

...

ther eare some convince factors to github and many

inconvenices.,

...

...

...

...

...

it has a vastly inferior code review model that if i was force

to use

...

...

...

would push me out of the openstack comunity long term.

...

...

im sure there are others too that feel stongly that moving to a

github

...

...

...

pull request based workflow woudl be a large regerssion

...

...

and make them less inclined to continue working on openstack.

The thread is being very explicit about external projects and not

the

...

...

...

OpenStack itself. yep but that is unhelpful. if any external project that work with openstack want to become

part of

...

...

...

openstack under the foundatiosn governace it is nolonger external.

so if gophercloud was to become part of openstack it would not be

external

...

...

...

and if it wanted to you github pull requests for it workflow it woudl be deviating form the other openstack

projects.

...

...

...

external project that are not part of openstack governacne can use

any

...

...

...

tooling they like.

if we start allowing arbiatry internal and external project to use

gerrit

...

...

...

or github workflows of worse both concurrently we will start getting request to supprot that for other proejct

like nova

...

...

...

neutron ectra. i woudl see that as damaging to the exsting colaberator based and something to be avoided if we

can.

...

...

...

im not really sure what gophercloud want to achive by being part of openstack without adopting the openstack ways of doing things that they cant acive by bing a nice go sdk for openstack on there own with the well wishes and or support of the openstack comunity.

the 4 opens are a core part of the culture of openstack simiarly the ways of workign with irc/gerrit/zuul/ptgs are also a

part of

...

...

...

the openstack way.

i am wondering why gophercloud want to actully becoem an offial

proejct if

...

...

...

they dont want to adopt the open developement workflow (note i did

not say

...

...

...

model) that openstack uses?

I'm a Gophercloud maintainer and can provide some context. Some of us

at

...

...

Red Hat inherited the project ( https://github.com/gophercloud/gophercloud/issues/2246) at the end

of last

...

...

year. The first thing we did was to check if the project could fit

under the

...

...

opendev umbrella as it seemed like the natural place to us. The

discussion

...

...

was run in the open:

https://github.com/gophercloud/gophercloud/issues/2257

...

...

and

http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025660....

...

...

The main reasons were:

• Gain more sustainability, contributors around the community and more

diversity in maintainers

• More stable CI (not relevant anymore since we moved to Github

Actions,

...

...

and we do not rely on openlab anymore)

• CI integration in other projects
• Better governance

Thanks for that context.

with that in mind im not sure it makes sense to proceed with movign it

under openstack

...

governance.

i agree that it woudl be nice form a governance perspective to include

it under the sdk team

...

but if the opendev ways or workign dont work for the existing

contibutor base im not sure

...

it makes sense for ether comuntiy i do agree these ^ are good reasons

to consider this change

...

but im not conviced it woudl be good for openstack to add github

hosting and review workflow.

I might agree on all those points of not splitting the tooling but considering the current situation, I do not think we will have any new contributors in Gophercloud or any of the existing contributors will be contributing in Gophercloud so it hardly matters from the contributors' point of view if that is in GitHub or OpenDev. If SDK team is ok with Github then I think we should be ok.

Yes, if we have a few existing contributors who want to contribute to Gophercloud then it makes sense to have it in OpenDev otherwise I feel like we are stuck on process which can be more beneficial if we change it.

-gmann

...

...

When we asked the Gophercloud contributors about using gerrit, the

feedback

...

...

wasn't positive (details in #2257) so at this point we decided to not proceed further at the time. Due to the nature of the project, a lot of our pull-requests are

"drive-by

...

...

contributions" (e.g. to add new fields to the API) by new

contributors;

...

...

which ought to be considered if we were going to Gerrit.

That being said, if we get more contributions from the OpenStack

community,

...

...

this would certainly help to justify the move under opendev.

Agree here. At some point in time processes might need to change to allow growth or any evolution.

I second that. It reminds me the Storyboard and Launchpad thing, where some projects are using one and others the other one bug tracker so new people don't even exactly know where they should report bug against particular project. If we will have some projects hosted on opendev and using Gerrit and others hosted on Github only and using Github's workflow, it will be IMO similar mess.

Agree.

--Dan

On Fri, Jun 24, 2022 at 7:47 AM Thomas Goirand zigo@debian.org wrote:

On 6/21/22 17:34, Clark Boylan wrote:

...

This isn't the only instance we've run into this. The CNCF's Cloud Native landscape (https://landscape.cncf.io/) requires open source projects be hosted on Github (not not proprietary systems....). From my perspective, I think this calls out why it is important for us to continue to push back against these rules. Software is built in a number of places and if we force people to use Github (and other proprietary tools) we move away from part of the mission here.

I very much agree here, especially considering that Github is a non-free platform. If it was hosted let's say on *any* Gitlab instance, I would think differently.

...

I think this calls out the fundamental disconnect here. We use open source tools because we believe that open source needs and should be built with open source tools. That does require a little bit of investment from the project side to ensure the tooling functions as needed and is maintained.

Yeah, definitively!

Thanks a lot to the infra team for insisting on these subjects. OpenStack wouldn't be where it is without you guys.

+2 +W

We wouldn't be as successful as a community without the tools you have worked so hard on to keep us moving forward!

Cheers,

Thomas Goirand (zigo)

-Kendall Nelson