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