<div dir="ltr"><div class="gmail_default" style=""><font face="times new roman, serif" style="">By the fact that you are </font>completely<font face="times new roman, serif" style=""> dodging the question ("</font><span style="font-family:Arial,Helvetica,sans-serif">A person in Kenya will be better off by having Oslo merged with Berlin because:..."), </span><font face="times new roman, serif" style="">my only conclusion can be that in fact you have no answer; that you cannot spell out a concrete case where a person in Kenya is disadvantaged by the merger of Oslo with Berlin. Why make a change if it doesn't help anyone, and has the potential to do considerable damage?</font></div><div class="gmail_default" style=""><font face="times new roman, serif"><br></font></div><div class="gmail_default" style=""><font face="times new roman, serif">Secondly, your analogy with COVID is even more misplaced. Instead of "</font>If we give COVID-19 shots to people in San Francisco but not Los Angeles, purely for reasons unrelated to public health<span class="gmail_default" style="font-family:"times new roman",serif">...", what you are proposing is analogous to <b>de-vaccinating</b> all the people in San Francisco so that they are on the same level as Los Angeles. That is a pretty extreme form of "equity".</span></div><div class="gmail_default" style=""><span class="gmail_default" style="font-family:"times new roman",serif"><br></span></div><div class="gmail_default" style=""><span class="gmail_default" style="font-family:"times new roman",serif">I'm sure you're trying to do the right thing here, but the nearly unanimous response to your proposal should give you pause, and give us all time to consider issues that have been raised. During my career I've seen many cases where it seemed that some small quick change would have some benefit, but it had to be retracted when it blew up in our faces. Being a core piece of technology for all computers, mobile phones, etc. with many, many players all needing to work in concert so that everything interoperates is a heavy responsibility, and not one to be taken lightly. Please don't rush into this.</span></div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 24, 2021 at 12:09 AM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/23/21 9:00 PM, Mark Davis ☕ wrote:<br>
> My chief concern is instability and incompatibility<br>
<br>
2021a1 will give you maximum stability and compatibility with 2021a, so <br>
you can use that if equity is not as much of a concern for you.<br>
<br>
> why is it so very, very important to make this change right now<br>
<br>
The equity issue has been on the table for months, no other approach has <br>
been developed or tested, and the only other approaches proposed would <br>
be less stable and compatible than the already built-and-tested 2021b <br>
would be.<br>
<br>
The equity issue was raised early this year, and we've delayed dealing <br>
with it for far too long already. Equity is a real issue of concern, and <br>
it's a bad look for us if we continue with a clearly-inequitable primary <br>
distribution when a fairer approach has long been implemented and <br>
available and nothing else is available.<br>
<br>
This is mostly a disagreement about maintenance philosophy not end-user <br>
functionality, as the pre-1970 differences between 2021a1 and 2021b will <br>
be minor when considered from end users' point of view. We know this <br>
because we've made similar changes many times in previous releases.<br>
<br>
I'll be happy to collaborate on building something that will accommodate <br>
our philosophical differences in later releases, and have already <br>
proposed specific (though not-yet-installed) working code that goes a <br>
long way toward doing that. Having had some experience with writing and <br>
testing that code, I have confidence that this technical approach will <br>
succeed if the community wants to work together on this. Of course there <br>
will be issues - among other things, the <br>
at-least-one-Zone-per-country-code philosophy is even more <br>
unstable/incompatible than 2021b will be - but they're clearly solvable.<br>
</blockquote></div>