Well put Monty. It is a tough choice and neither choice was inexpensive. -amrith
> -----Original Message----- > From: Monty Taylor [mailto:mord...@inaugust.com] > Sent: Tuesday, June 07, 2016 3:00 PM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] Reasoning behind my vote on the Go topic > > This text is in my vote, but as I'm sure there are people who do not > read all of the gerrit comments for governance changes, I'm posting it > here so that my thoughts are clear. > > Please know that this has actually kept me up at night. I cast my vote > on this neither glibly or superficially. I have talked to everyone I can > possibly think of on the topic, and at the end, the only thing I can do > is use my judgment and vote to the best of my ability. I apologize from > the bottom of my heart to the people I find myself in disagreement with. > I have nothing but the utmost respect for you all. > > I vote against allowing Go as an official language of OpenStack. > > "The needs of the many outweigh the needs of the few, or the one" > > I'm super unhappy about both possible votes here. > > I think go is a wonderful language. I think hummingbird is a well > considered solution to a particular problem. I think that lack of > flexibility is broadly speaking not a problem we have in OpenStack > currently. I'm more worried about community cohesion in a post-Big Tent > world than I am about specific optimization. > > I do not think that adding Go as a language to OpenStack today is enough > of a win to justify the cost, so I don't like accepting it. > > I do not think that this should preclude serious thought about > OpenStack's technology underpinnings, so I don't like rejecting it. > > "only a great fool would reach for what he was given..." > > I think that one of OpenStack's biggest and most loudly spoken about > problems is too many per-project solutions and not enough holistic > solutions. Because of that, and the six years of experience we have > seeing where that gets us, I do not think that adding Go into the mix > and "seeing what happens" is going to cause anything other than chaos. > > If we want to add Go, or any other language, into the mix for server > projects, I think it should be done with the intent that we are going to > do it because it's a markedly better choice across the board, that we > are going to rewrite literally everything, and I believe that we should > consider the cost associated with retraining 2000 developers as part of > considering that. Before you think that that's me throwing the baby out > with the bathwater... > > In a previous comment, Deklan says: > > "If Go was accepted as an officially supported language in the OpenStack > community, I'd be the first to start to rewrite as much code as possible > in Go." > > That is, in fact, EXACTLY the concern. That rather than making progress > on OpenStack, we'll spend the next 4 years bikeshedding broadly about > which bits, if any, should be rewritten in Go. It took Juju YEARS to > rewrite from Python to Go and to hit feature parity. The size of that > codebase was much smaller and they even had a BDFL (which people keep > telling us makes things go quicker) > > It could be argued that we could exercise consideration about which > things get rewritten in Go so as to avoid that, but I'm pretty sure that > would just mean that the only conversation the TC would have for the > next two years would be "should X be in Go or Python" - and we'd have > strong proponents from each project on each side of the argument. > > David Goetz says "you aren’t doing the community any favors by deciding > for them how they do their jobs". I get that, and can respect that point > of view. However, for the most part, the negative feedback we get as > members of the TC is actually that we're too lax, not that we're too > strict. > > I know that it's a popular sentiment with some folks to say "let devs > use whatever tool they want to." However, that has never been our > approach with OpenStack. It has been suggested multiple times and > aligning on limited chosen tech has always been the thing we've chosen. > I tend to align in my personal thinking more with Dan McKinley in: > > http://mcfunley.com/choose-boring-technology > > I have effectively been arguing his point for as long as I've been > involved in OpenStack governance - although probably not as well as he > does. I don't see any reason to reverse myself now. > > I'd rather see us focus energy on Python3, asyncio and its pluggable > event loops. The work in: > > http://magic.io/blog/uvloop-blazing-fast-python-networking/ > > is a great indication in an actual apples-to-apples comparison of what > can be accomplished in python doing IO-bound activities by using modern > Python techniques. I think that comparing python2+eventlet to a fresh > rewrite in Go isn't 100% of the story. A TON of work has gone in to > Python that we're not taking advantage of because we're still supporting > Python2. So what I've love to see in the realm of comparative > experimentation is to see if the existing Python we already have can be > leveraged as we adopt newer and more modern things. > > In summary, while I think that Go is a lovely language and the people > who work on it are lovely people, while I'm sure that hummingbird is > beneficial to the Cloud Files team in real ways and while I'm sure that > if we were starting OpenStack from scratch today the conversations about > how to do it might be different, I put a large value on the code and the > community we've built and I want any decisions that we make about things > as large as this to take the code, the people, the process and the > results into account. > > That said, this is a democracy. I am but one vote, and I've been both > wrong and on the losing side of an opinion before. I've already > upstreamed changes to Go to make doing code in git.openstack.org more > pleasant. I think zuul-cloner needs to learn about go source code > organization regardless of the outcome of this decision. As always, I > will both abide by and whole-heartedly support the decision of the > democratically elected governance body, whether it matches my current > opinion on this extremely hard and non-straightforward question or not. > Although I know we're all fans of hyperbole around here, I certainly > hope that everyone else who is involved and who has voluntarily agreed > to be a part of this organization of humans with this mode of governance > will do the same. Democracy is easy when we all agree, the real work > comes when we don't get our way. > > Monty > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
