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