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. DougThis. 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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
