On 7 Nov 2016, at 10:31, Ash wrote:
> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham <graham.ha...@hpe.com> 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 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: 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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
