---- 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
[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