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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
