If we let go in, and there are no pluggable middleware, where does RadosGW and other Swift api compatible implementations then stand? Should we bless c++ too? As I understand it, there are a lot of clouds deployed with the RadosGW but Refstack rejects them.
Thanks, Kevin ________________________________________ From: Doug Hellmann [d...@doughellmann.com] Sent: Tuesday, May 03, 2016 2:50 PM To: openstack-dev Subject: Re: [openstack-dev] [tc] supporting Go 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 <m...@not.mn > >> <mailto:m...@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 > > --John > > > > > [1] http://governance.openstack.org/reference/project-testing-interface.html __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev