Open Stack

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
>