[openstack-dev] [all] Embracing new languages in OpenStack
Doug Hellmann
doug at doughellmann.com
Tue Nov 8 16:52:58 UTC 2016
Excerpts from Flavio Percoco's message of 2016-11-08 08:33:41 -0800:
> On 08/11/16 16:20 +0000, Hayes, Graham wrote:
> >On 08/11/2016 15:55, Doug Hellmann wrote:
> >> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +0000:
> >>> On 08/11/2016 10:30, Thierry Carrez wrote:
> >>>> Ash wrote:
> >>>>> [...]
> >>>>> 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?
> >>>>
> >>>> The TC isn't just one person. In complex situations like this where you
> >>>> have to weigh the trade-off between opening up more choices and our
> >>>> community's ability to digest/survive the change, there will always be a
> >>>> wide variety of opinions. I won't claim to be able to predict how the
> >>>> current membership would vote.
> >>>
> >>> Yup - and the TC could possibly change half, (or even all) its members
> >>> during time it takes to get this work done.
> >>>
> >>>> That said, I think that if we can have more confidence that our
> >>>> structure can handle it (from infra to release/stable/dep management)
> >>>> and that the OpenStack community will share expertise and best practices
> >>>> on Go and avoid reinventing the wheel in every project, I expect a
> >>>> majority of TC members to take that leap of faith.
> >>>
> >>> There was a bit of work done for the previous proposal, but the main
> >>> objections were not to do with any of points raised in this email /
> >>> blog. The objections were mainly cultural - about how it would impact
> >>> the community (which *is* very important), and the exactly why it was
> >>> needed for the projects who were asking.
> >>>
> >>>> To me, the important part is that introducing Go should not be another
> >>>> way for some of our community to be different, but another way for our
> >>>> community to be one. It should do more to bind our community together
> >>>> than to split it into more factions and silos.
> >>>>
> >>>
> >>> I would agree - but I would ask that we find a way forward that does not
> >>> require huge amounts of up front work, for a gamble at the end of the
> >>> process, where the work could be written off for any number of other
> >>> reasons.
> >>>
> >>
> >> I agree that we need to be careful about how much up-front work is
> >> required. A plan to address some of these concerns seems like a
> >> minimum level, with commitment to handle the immediate items like
> >> infra resources for managing those changes. But it's hard to specify
> >> the right levels in the abstract, because so much depends on the
> >> situation, language, and teams involved.
> >>
> >> Doug
> >
> >This. I think trying to define objective rules, procedures, and
> >checklists for what is at the end of the a subjective decision is
> >not a great idea.
> >
> >Should the policy just be "If you want to add a new language, add an
> >item to the TC agenda. They will the discuss the overall proposal, and
> >may ask for more details in the following areas, the use case, or decide
> >that this is not a direction that the community should proceed towards."
> >
> >Or, you know, a well written version of ^.
>
> This feels a lot like what we have today. I think the set of requirements must
> be written down and clear. The evaluation of the use case should still happen
> and it'd be better for it to happen before the up-front work is done. There will
> always be work to do up front for any new language being added to the community.
>
> Also, for the evaluation of the use case, it'd be awesome to have the use case
> presented to the mailing list before the item is even added to the TC agenda. I
> liked the review that other members of the community did with the Swift
> proposal.
>
> Flavio
>
Right. I like the idea of having a list of expectations for what would
need to be done *eventually* to fully support a new language. Then when
there's a concrete request, the discussion can focus on whether those
things apply and if so what the timing needs to be.
Doug
More information about the OpenStack-dev
mailing list