[openstack-dev] [all] Embracing new languages in OpenStack
me at not.mn
Mon Nov 7 18:51:06 UTC 2016
On 7 Nov 2016, at 10:31, Ash wrote:
> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham <graham.hayes at hpe.com> wrote:
>> On 07/11/2016 17:14, Flavio Percoco wrote:
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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
>> We need to also include
>> Do they *all* need to be implemented? Just some? Do they need feature
>> 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.
>> 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
>>> The longer and more detailed version is here:
>>> Stay tuned,
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev