Open Stack

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:
>>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161107/583ee9d3/attachment.pgp>