[openstack-dev] [tc] supporting Go
Robert Collins
robertc at robertcollins.net
Thu May 12 19:04:33 UTC 2016
On 13 May 2016 at 00:01, Thierry Carrez <thierry at openstack.org> wrote:
> Robert Collins wrote:
>>
>> [...]
>> So, given that that is the model - why is language part of it? Yes,
>> there are minimum overheads to having a given language in CI [...]
>
>
> By "minimum" do you mean that they are someone else's problem ?
No. I mean that there is an irreducible cost: there is some minimum
and we need to account for that. (as in fact the end of that paragraph
which you snipped, said).
> There are economics at play here. Adding a language simplifies the work of
> some and make more work for others. Obviously "some" see mostly benefits and
> "others" see mostly drawbacks. You're just creating an externality[1].
I'm not sure that allowing arbitrary languages would constitute an
externality, properly structured - which is what I was trying to get
at with my mail.
> So rather than shifting workloads to someone else or pretending there is no
> problem, let's take the time to calmly measure the cost, see what resources
> we have lined up to address that cost, and make a decision from there.
I proposed neither of those things (shifting, or pretence). Rebutting
those positions is not rebutting my argument.
I agree with taking the time to assess things carefully, but in this
discussion noone had taken a general 'pro' stance, so I decided, as an
exercise, to write one up.
However, assessing 'what we have to address that cost' is missing the
actual point: we don't need to cover the cost /once/, we need to make
how-its-covered, and who-covers-it be structured such that folk
wanting to use $LANGUAGE provide the [human] resources needed to cover
the incurred costs. An answer which says 'we can just afford to pay
for go, but thats it', is an answer that has failed to actually tackle
the underlying problem.
-Rob
--
Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud
More information about the OpenStack-dev
mailing list