<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham <span dir="ltr"><<a href="mailto:graham.hayes@hpe.com" target="_blank">graham.hayes@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/11/2016 17:14, Flavio Percoco wrote:<br>
> Greetings,<br>
><br>
> I literally just posted a thing on my blog with some thoughts of what I'd expect<br>
> any new language being proposed for OpenStack to cover before it can be<br>
> accepted.<br>
><br>
> The goal is to set the expectations right for what's needed for new languages to<br>
> be accepted in the community. During the last evaluation of the Go proposal I<br>
> raised some concerns but I also said I was not closed to discussing this again<br>
> in the future. It's clear we've not documented expectations yet and this is a<br>
> first step to get that going before a new proposal comes up and we start<br>
> discussing this topic again.<br>
><br>
> I don't think a blog post is the "way we should do this" but it was my way to<br>
> dump what's in my brain before working on something official (which I'll do<br>
> this/next week).<br>
><br>
> I also don't think this list is perfect. It could either be too restrictive or<br>
> too open but it's a first step. I won't paste the content of my post in this<br>
> email but I'll provide a tl;dr and eventually come back with the actual<br>
> reference document patch. I thought I'd drop this here in case people read my<br>
> post and were confused about what's going on there.<br>
><br>
> Ok, here's the TL;DR of what I believe we should know/do before accepting a new<br>
> language into the community:<br>
<br>
</span>Its a great starting point, but there is one issue:<br>
<br>
This is a *huge* amount of work to get into place, for the TC to still<br>
potentially refuse the language. (I know you covered this in your blog<br>
post, but I think there is a level of underestimation there.)<br>
<span class=""><br>
<br>
> - Define a way to share code/libraries for projects using the language<br>
<br>
</span>++ - Definitely needed<br>
<span class=""><br>
> - Work on a basic set of libraries for OpenStack base services<br>
<br>
</span>What do we include here? You called out these:<br>
<br>
keystoneauth / keystone-client<br>
oslo.config<br>
oslo.db<br>
oslo.messaging<br>
<br>
We need to also include<br>
<br>
oslo.log<br>
<br>
Do they *all* need to be implemented? Just some? Do they need feature<br>
parity?<br>
<br>
For example the previous discussion about Go had 2 components that would<br>
have required at most 2 of these base libraries (and I think that was<br>
mainly on the Designate side - the swift implementation did not need<br>
any (I think - I am open to correction)<br>
<span class=""><br>
> - Define how the deliverables are distributed<br>
<br>
</span>++ - but this needs to be done with the release management teams input.<br>
What I think is reasonable may not be something that they are interested<br>
in supporting.<br>
<span class=""><br>
> - Define how stable maintenance will work<br>
<br>
</span>++<br>
<span class=""><br>
> - Setup the CI pipelines for the new language<br>
<br>
</span>This requires the -infra team dedicate (what are already stretched)<br>
resources to a theoretical situation, doing work that may be thrown<br>
away if the TC rejects a language.<br></blockquote><div>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. </div><div><br></div><div>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? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I foresee these requirements as a whole being overly onerous, and<br>
having the same result as saying "no new languages".<br>
<br>
I think that there should be base research into all of these, but the<br>
requirements for some of these to be fully completed could be basically<br>
impossible.<br>
<span class="im HOEnZb"><br>
><br>
> The longer and more detailed version is here:<br>
><br>
> <a href="https://blog.flaper87.com/embracing-other-languages-openstack.html" rel="noreferrer" target="_blank">https://blog.flaper87.com/<wbr>embracing-other-languages-<wbr>openstack.html</a><br>
><br>
> Stay tuned,<br>
> Flavio<br>
><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>