Open Stack

Excerpts from Hayes, Graham's message of 2016-05-05 07:26:26 -0700:
> On 04/05/2016 00:32, Hayes, Graham wrote:
> > On 03/05/2016 17:03, John Dickinson wrote:
> >> TC,
> >>
> >> In reference to http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and Thierry's reply, I'm currently drafting a TC resolution to update http://governance.openstack.org/resolutions/20150901-programming-languages.html to include Go as a supported language in OpenStack projects.
> >>
> >> As a starting point, what would you like to see addressed in the document I'm drafting?
> >>
> >> --John
> >>
> >>
> >>
> >
> > Great - I was about to write a thread like this :)
> >
> > Designate is looking to move a single component of ours to Go - and we
> > were wondering what was the best way to do it.
> >
> > The current policy does allow for the TC to bless different languages
> > on a case by case basis - do we need to go from just python and JS to
> > allowing all projects to use go, or should the TC approve (or
> > disapprove) the swift and designate requests?
> >
> > I think the swift and designate changes might be a good test case to
> > see how the build / mirroring / packaging / artifact / library issues
> > shake out.
> >
> > - Graham
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> So, as part of the update to that policy, should we have an
> "OpenStack Go developer guide" that lays out how we think we will
> implement go in our stack.
> 
> I am sure it will not be complete, or even correct for what we actually
> do in the end, but it could give us a place to try and come to a shared
> understanding.
> 

I think I share your desire, to have something concrete on the table
before the TC (I'm not a TC member) considered this. However, I would
want to make sure the barrier isn't so high as to discourage progress.

I would love for the team(s) proposing Go code to provide whatever they
have now as a base for such a document. I would support the minimum
amount of effort to just reformat and reorganize that document so that
it resembles our python oriented guides, and start from there.

I doubt anyone not writing Go regularly will have much practical to
say about the details, but the community as a whole can review it and
be sure that the teams making the proposal share the same orientation
toward developers as we have for python development.