Open Stack

Excerpts from John Dickinson's message of 2016-05-03 15:05:08 -0700:
> 
> On 3 May 2016, at 14:50, Doug Hellmann wrote:
> 
> > Excerpts from John Dickinson's message of 2016-05-03 13:01:28 -0700:
> >>
> >> On 3 May 2016, at 12:19, Monty Taylor wrote:
> >>
> >>> On 05/03/2016 01:45 PM, Michael Krotscheck wrote:
> >>>> On Tue, May 3, 2016 at 9:03 AM John Dickinson <me at not.mn
> >>>> <mailto:me at not.mn>> wrote:
> >>>>
> >>>>
> >>>>     As a starting point, what would you like to see addressed in the
> >>>>     document I'm drafting?
> >>>>
> >>>>
> >>>> I'm going through this project with JavaScript right now. Here's some of
> >>>> the things I've had to address:
> >>>>
> >>>> - Common language formatting rules (ensure that a pep8-like thing exists).
> >>>> - Mirroring dependencies?
> >>>> - Building Documentation
> >>>
> >>> Mirroring and building are the ones that we'll definitely want to work together on in terms of figuring out how to support. go get being able to point at any git repo for depends is neat - but it increases the amount of internet surface-area in the gate. Last time I looked (last year) there were options for doing just the fetch part of go get separate from the build part.
> >>>
> >>> In any case, as much info as you can get about the mechanics of downloading dependencies, especially as it relates to pre-caching or pointing build systems at local mirrors of things holistically rather than by modifying the source code would be useful. We've gone through a couple of design iterations on javascript support as we've dived in further.
> >>
> >> Are these the sort of things that need to be in a resolution saying that it's ok to write code in Golang? I'll definitely agree that these questions are important, and I don't have the answers yet (although I expect we will by the time any Golang code lands in Swift). We've already got the Consistent Testing Interface doc[1] which talks about having tests, a coding style, and docs (amongst other things). Does a resolution about Golang being acceptable need to describe dependency management, build tooling, and CI?
> >
> > There are separate interfaces described there for Python and JavaScript.
> > I think it makes sense to start documenting the expected interface for
> > projects written in Go, for the same reason that we have the others, and
> > I don't think we would want to say "Go is fine" until we at least have a
> > start on that documentation -- otherwise we have a gap where projects
> > may do whatever they want, and we have to work to get them back into
> > sync.
> >
> > Doug
> >
> 
> Yeah, I see that. Can you help me come up with that list? I honestly don't know the "right" way to do everything in Go. These are some of the things that need to be sussed out over the next several months (see the original email).
> 
> I've proposed my initial draft to https://review.openstack.org/#/c/312267/. I'd be happy if you pushed over that or had a follow-on patch to help describe the interfaces like with JS and Python.

I can try to work with you on that, but not being a Go programmer myself
I'm not sure I'll have answers. Your best bet is to start by identifying
the analogous operations. A few off the top of my head:

- How do you run unit tests? Do you need to do that for multiple versions
  of the language like we do with Python 2.7 and 3.x?

- How about code coverage as part of the tests?

- How do you manage dependencies? How does that fit with our global
  requirements and constraints lists pattern we have for Python apps?

- How do you build source packages?

- Should we be building binary packages in some format (what's usual
  for go?) and if so, what format?

- How will you manage in-tree documentation? Sphinx works fine
  stand-alone, so maybe stick with the existing pattern there?

- How will you handle log and message string translations? Are there new
  tools we need to add to our CI images?

- How would devstack install the project as part of a gate job?

Does go typically use a Makefile for these things, or some other driving
tool? Can the same tool be used across all projects with the same
targets ("make test", etc.) for consistency and to make the CI system
setup easier?

Doug