From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 546E046971A for ; Mon, 9 Dec 2019 17:07:15 +0300 (MSK) Date: Mon, 9 Dec 2019 17:07:13 +0300 From: Nikita Pettik Message-ID: <20191209140713.GA57435@tarantool.org> References: <20191129233922.36600-1-k.sosnin@tarantool.org> <20191130203439.GA23478@atlas> <13437800-f8ec-1964-f7d7-a01581e242ad@tarantool.org> <20191202070715.GA27802@atlas> <20191206114244.umbeo556b2atuhjm@tarantool.org> <20191206201718.GA7299@atlas> <20191209110631.srknhyc3zpn5cjsy@tarantool.org> <20191209112428.GB25729@atlas> <20191209132555.qn25wsxoa5lr4252@tarantool.org> <20191209133955.GA8196@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191209133955.GA8196@atlas> Subject: Re: [Tarantool-patches] [PATCH] box: remove unicode_ci for functions List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Kirill Yukhin , Vladislav Shpilevoy , Chris Sosnin , tarantool-patches@dev.tarantool.org On 09 Dec 16:39, Konstantin Osipov wrote: > * Kirill Yukhin [19/12/09 16:28]: > > > Who is "we"? > > > > We are team of Tarantool developers working for MailRU Group. > > Actually this decision was made without any discussions - it was > quickly hacked in back in 2018. Maybe you and Nikita had some > discussion prompted by Peter's firm stance that we should > uppercase, but that was it. I didn't participate in any discussion at that time. When I came in Tarantool decision had been already taken. I do not know who is responsible for that. IMHO rather than attempt to fix it now, I'd better improve tutorials and docs by placing most common examples/mistakes at the front page. > I protested several times while I > was still on board but had not anticipated how bad the solution > would turn out to be when it is implemented to follow through on > time. Now it is still not to late - bit it's getting more late > every day. > > What we learned since then is that every single newbie trips over > it. > > > > We had pretty much discussions internally on the matter and > > came up with this decision: we won't break backward compatibility > > in order to add some sugar. > > What backward compatibility do you think will be broken? > > > > > > > I don't see this has been discussed & rejected, so why are you > > > thinking you can make this decision? > > > > All I can see on the matter is issue #4467 which we agreed to > > be broken by design. I see no solid proposals neither in discussions > > nor in github issues on how it supposed to work. If it will occur - > > we'll happily consider it. > > > > > Maybe "we" instead of making "decisions" goes to users and > > > customers and asks them what they expect? > > > > Why not to ask if public demands free beer? Right now business > > dictates us to work on other things. > > Like Chris patch? > > -- > Konstantin Osipov, Moscow, Russia