Open Stack

On 11/07/2016 12:51 PM, John Dickinson wrote:
> 
> 
> 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've just added a few more notes to it - turns out time has elapsed
since last May. :)

>>>
>>> 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
>>
>>
>> __________________________________________________________________________
>> 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/c79b1eaf/attachment.pgp>