<div dir="ltr"><div><div><div><div><div>My take would be to select no more than 3 languages, according what they are needed for,<br></div>then let the Service Team pick the best one right for what it needs to be done.<br></div><div><br></div><div>Something like:<br><br></div><div>- Do you need more performance for this component in your service? OK, use this.<br></div><div>- Do you need Web and alike? Ok, use that.<br></div><div>- General and Default: Python.<br></div><div>- Anything else? Then you can use this.<br></div><div><br></div><div>With this approach we would cover the needs of developers that have to implement services and at the same time provide options for languages that are better suited for related use cases.<br><br></div><div>All the gating, tests and alike will be focused on those selected languages.<br><br></div><div>This would also solve discussions in the future, as if for instance a new language is proposed for performances, then we would already have a solution for that. At the same time we would have an open approach to alternatives, but only to those alternatives, not any and still be able to keep control and focus.<br><br></div><div>Thanks,<br></div><div>Fausto<br><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 9:04 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</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 13 May 2016 at 00:01, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
> Robert Collins wrote:<br>
>><br>
>> [...]<br>
>> So, given that that is the model - why is language part of it? Yes,<br>
>> there are minimum overheads to having a given language in CI [...]<br>
><br>
><br>
> By "minimum" do you mean that they are someone else's problem ?<br>
<br>
</span>No. I mean that there is an irreducible cost: there is some minimum<br>
and we need to account for that. (as in fact the end of that paragraph<br>
which you snipped, said).<br>
<span class=""><br>
> There are economics at play here. Adding a language simplifies the work of<br>
> some and make more work for others. Obviously "some" see mostly benefits and<br>
> "others" see mostly drawbacks. You're just creating an externality[1].<br>
<br>
</span>I'm not sure that allowing arbitrary languages would constitute an<br>
externality, properly structured - which is what I was trying to get<br>
at with my mail.<br>
<span class=""><br>
> So rather than shifting workloads to someone else or pretending there is no<br>
> problem, let's take the time to calmly measure the cost, see what resources<br>
> we have lined up to address that cost, and make a decision from there.<br>
<br>
</span>I proposed neither of those things (shifting, or pretence). Rebutting<br>
those positions is not rebutting my argument.<br>
<br>
I agree with taking the time to assess things carefully, but in this<br>
discussion noone had taken a general 'pro' stance, so I decided, as an<br>
exercise, to write one up.<br>
<br>
However, assessing 'what we have to address that cost' is missing the<br>
actual point: we don't need to cover the cost /once/, we need to make<br>
how-its-covered, and who-covers-it be structured such that folk<br>
wanting to use $LANGUAGE provide the [human] resources needed to cover<br>
the incurred costs. An answer which says 'we can just afford to pay<br>
for go, but thats it', is an answer that has failed to actually tackle<br>
the underlying problem.<br>
<span class="im HOEnZb"><br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hpe.com">rbtcollins@hpe.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>