---- On Sun, 18 Aug 2019 03:38:05 +0900 Jeremy Stanley <fungi@yuggoth.org> wrote ----
On 2019-08-17 14:34:11 +0800 (+0800), Douglas Zhang wrote:
My colleagues and me have been working on an openstack admin project(like horizon, but more efficient) using Golang, and now we are willing to contribute it to openstack community.
Well, just to make sure you understand the culture, you don't really "contribute [software] to OpenStack" so much as you develop software within the OpenStack community. OpenStack is about the process of openly designing and creating infrastructure software, so anything written in private behind closed doors and then exposed to the light of day is going to suffer accordingly. Building a community around and maintaining/improving your project are going to be substantially more important if the project wasn't a public collaboration from its very inception.
As explained by Jeremy, contributing projects to OpenStack also involve maintaining it we per common standard of OpenStack. For example, active contributors, project leader (PTL) etc. If you have not checked the exact requirements of new project, you can refer to this doc[1].
While looking through the project creators' guide [1], we have met some questions that need to be answered:
As this project is written by go, it is not possible to register it on PyPI, would this have any influence? Would openstack community accept golang projects as its related projects?
The OpenStack Technical Committee has previously entertained allowing projects in Go, and voted in favor of a resolution[*] to that effect. The gist of that decision was that deviating from the OpenStack language norms (primarily Python with some JavaScript for Web interfaces and Bash for shell automation) is allowable if it's done because it's reasonably challenging to meet the goals of the project otherwise. To restate, I don't know that OpenStack would accept a project written in Go if the reason it's being asked to do so is "well, we've already written it and we chose Go because we like the language." As I said earlier, OpenStack projects are normally designed and built collaboratively within the OpenStack community, and any time people have come to us with something they already wrote outside the community that they want to add, it's generally not gone that well for a number of reasons.
I am not sure if the swift requirement of GO lang went to second step[2] and we have all the CI setup etc. The main challenge I see for any new language is from horizontal support team like QA, Infra, release team etc especially in the current situation where most of those team have less number of maintainers. But yes, we should first discuss the technical requirement of the new project and why GO language is must for it. Based on that we can proceed for further support. I will suggest you start the ML discussion about 'what is the project', 'its use case' and 'why GO lang'.
If it's the case that Go was chosen because the thing you want to accomplish simply cannot be done (or at least can't be done with the necessary efficiency) in one or more of OpenStack's primary languages, we do maintain a Project Testing Interface definition[**] for Go. It's not been well-exercised and so may still reflect the state of the Go ecosystem as it was when drafted two years ago, in which case we welcome help improving it to better represent modern Go software development expectations.
[*] https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.htm... [**] https://governance.openstack.org/tc/reference/pti/golang.html
[1] https://governance.openstack.org/tc/reference/new-projects-requirements.html [2] https://governance.openstack.org/tc/reference/new-language-requirements.html -gmann
-- Jeremy Stanley