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. 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
