Open Stack

My take would be to select no more than 3 languages, according what they
are needed for,
then let the Service Team pick the best one right for what it needs to be
done.

Something like:

- Do you need more performance for this component in your service? OK, use
this.
- Do you need Web and alike? Ok, use that.
- General and Default: Python.
- Anything else? Then you can use this.

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.

All the gating, tests and alike will be focused on those selected languages.

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.

Thanks,
Fausto


On Thu, May 12, 2016 at 9:04 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> 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
>
> __________________________________________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/0715b985/attachment.html>