Open Stack

On 08/11/2016 16:39, Flavio Percoco wrote:
> 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.

Yes - and that sentence covers the initial use case discussion, and
also allows for the more subjective criteria to be evaluated before the
up front work is started.

 >> more details in the following areas

In my mind this would point to a list like the one presented here.

> 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.

Sure - I am assuming that projects will not be operating in a vacuum,
and will be taking about the proposal long before they put to the TC.

If that needs to be called out, it should be added.

> Flavio
>