osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Some questions about contributing a golang project


 ---- On Sun, 18 Aug 2019 03:38:05 +0900 Jeremy Stanley <fungi at 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.html
 > [**] 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
 >