From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 5EF52452566 for ; Fri, 15 Nov 2019 16:57:06 +0300 (MSK) Received: by mail-lf1-f67.google.com with SMTP id b20so8116206lfp.4 for ; Fri, 15 Nov 2019 05:57:06 -0800 (PST) Date: Fri, 15 Nov 2019 16:57:04 +0300 From: Konstantin Osipov Message-ID: <20191115135704.GA7713@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <27617293.E4uLSYyink@home.lan> <20191115015745.GA23299@atlas> <14579640.zJlKmNO63O@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14579640.zJlKmNO63O@home.lan> Subject: Re: [Tarantool-patches] [PATCH] Trigger on vclock change List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Georgy Kirichenko Cc: tarantool-patches@dev.tarantool.org * Georgy Kirichenko [19/11/15 09:43]: > 90% of tarantool core developers are sitting together in one room or just > call-available during the day. Also, please, tell us how many RFC responds you > saw from a somebody who is not a part of tarantool core team. So, you wish to > force the whole team to use only this inconvenient and unproductive (because > of long-latency responds) communication way because of your beliefs. > So I have the another look: each thing to be discussed should be discussed (or > brainstormed) verbally (because we are the tarantol TEAM members) first and > only then a well-designed RFC could be formed (or, maybe, you wish to have > lots of worthless RFCs but I no see any point here). I gave earlier in this thread concrete examples how active-active won't work. It didn't take me long. You chose to respond back with some vague claims and promises of magic. If you have a miracle design, and you happen to not want to send an RFC, you still can prove it by sending a patch. Last time it didn't work: your refused to send an RFC for in-memory WAL - and the patch can't pass the code review for over 3 months. All this suggests that the patch by Maria is simply not worth it. Whatever it is needed for may never happen - and even if it happens, it is most likely the wrong thing to do. -- Konstantin Osipov, Moscow, Russia