On 11/07/2016 12:51 PM, John Dickinson wrote: > > > On 7 Nov 2016, at 10:31, Ash wrote: > >> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham <[email protected]> wrote: >> >>> On 07/11/2016 17:14, Flavio Percoco wrote: >>>> Greetings, >>>> >>>> I literally just posted a thing on my blog with some thoughts of what >>> I'd expect >>>> any new language being proposed for OpenStack to cover before it can be >>>> accepted. >>>> >>>> The goal is to set the expectations right for what's needed for new >>> languages to >>>> be accepted in the community. During the last evaluation of the Go >>> proposal I >>>> raised some concerns but I also said I was not closed to discussing this >>> again >>>> in the future. It's clear we've not documented expectations yet and this >>> is a >>>> first step to get that going before a new proposal comes up and we start >>>> discussing this topic again. >>>> >>>> I don't think a blog post is the "way we should do this" but it was my >>> way to >>>> dump what's in my brain before working on something official (which I'll >>> do >>>> this/next week). >>>> >>>> I also don't think this list is perfect. It could either be too >>> restrictive or >>>> too open but it's a first step. I won't paste the content of my post in >>> this >>>> email but I'll provide a tl;dr and eventually come back with the actual >>>> reference document patch. I thought I'd drop this here in case people >>> read my >>>> post and were confused about what's going on there. >>>> >>>> Ok, here's the TL;DR of what I believe we should know/do before >>> accepting a new >>>> language into the community: >>> >>> Its a great starting point, but there is one issue: >>> >>> This is a *huge* amount of work to get into place, for the TC to still >>> potentially refuse the language. (I know you covered this in your blog >>> post, but I think there is a level of underestimation there.) >>> >>> >>>> - Define a way to share code/libraries for projects using the language >>> >>> ++ - Definitely needed >>> >>>> - Work on a basic set of libraries for OpenStack base services >>> >>> What do we include here? You called out these: >>> >>> keystoneauth / keystone-client >>> oslo.config >>> oslo.db >>> oslo.messaging >>> >>> We need to also include >>> >>> oslo.log >>> >>> Do they *all* need to be implemented? Just some? Do they need feature >>> parity? >>> >>> For example the previous discussion about Go had 2 components that would >>> have required at most 2 of these base libraries (and I think that was >>> mainly on the Designate side - the swift implementation did not need >>> any (I think - I am open to correction) >>> >>>> - Define how the deliverables are distributed >>> >>> ++ - but this needs to be done with the release management teams input. >>> What I think is reasonable may not be something that they are interested >>> in supporting. >>> >>>> - Define how stable maintenance will work >>> >>> ++ >>> >>>> - Setup the CI pipelines for the new language >>> >>> This requires the -infra team dedicate (what are already stretched) >>> resources to a theoretical situation, doing work that may be thrown >>> away if the TC rejects a language. >>> >> Here's another take on the situation. If there are people who genuinely >> wish to see a CI pipeline that can support something like Go, perhaps you >> can establish a prerequisite of working with the Infra team on establishing >> the new pipeline. In my opinion, this seems to be the major gate. So, if >> there's a clear path identified, resources provided, and the Infra team is >> ultimately benefitted, then I'm not sure why there should be another >> rejection. Just a thought. I know this proposal continues to come up and >> I'm a big fan of seeing other languages supported, especially Go. But I >> also understand that it can break things. Personally, I would even >> volunteer to work on such an Infra effort. >> >> BTW, it is quite possible that another group might feel the same >> constraints. It's perfectly reasonable. But if we can overcome such >> obstacles, would the TC still have a concern? > > > Here's the notes we had from last May when we started the Golang discussion > where we started working through these questions. > > https://etherpad.openstack.org/p/golang-infra-issues-to-solve
I've just added a few more notes to it - turns out time has elapsed since last May. :) >>> >>> I foresee these requirements as a whole being overly onerous, and >>> having the same result as saying "no new languages". >>> >>> I think that there should be base research into all of these, but the >>> requirements for some of these to be fully completed could be basically >>> impossible. >>> >>>> >>>> The longer and more detailed version is here: >>>> >>>> https://blog.flaper87.com/embracing-other-languages-openstack.html >>>> >>>> Stay tuned, >>>> Flavio >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > > >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
