Open Stack

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

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 829 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161108/de8a748f/attachment.pgp>