From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kostja.osipov@gmail.com>
Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com
 [209.85.167.66])
 (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 711B6452566
 for <tarantool-patches@dev.tarantool.org>;
 Sat, 16 Nov 2019 14:56:09 +0300 (MSK)
Received: by mail-lf1-f66.google.com with SMTP id l14so3383574lfh.10
 for <tarantool-patches@dev.tarantool.org>;
 Sat, 16 Nov 2019 03:56:09 -0800 (PST)
Date: Sat, 16 Nov 2019 14:56:07 +0300
From: Konstantin Osipov <kostja.osipov@gmail.com>
Message-ID: <20191116115607.GE14490@atlas>
References: <20191114125705.26760-1-maria.khaydich@tarantool.org>
 <14579640.zJlKmNO63O@home.lan> <20191115135704.GA7713@atlas>
 <3021966.aeNJFYEL58@home.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3021966.aeNJFYEL58@home.lan>
Subject: Re: [Tarantool-patches] [PATCH] Trigger on vclock change
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Georgy Kirichenko <georgy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

* Georgy Kirichenko <georgy@tarantool.org> [19/11/15 22:59]:
> Please, point me out first how your claims related to my approach. Because you 
> made no effort to understand the approach. Even did not ask for very brief 
> explanation.

Alright, you claim I am not asking for a brief explanation. I am
asking for an RFC, which is the best way to explain ideas we have.

But fine, I am asking you:
> > 
> > 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.
> The next wrong suggestion. I have a concrete design which was shared and 
> discussed.
>  > 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.
> Please read my previous message and find out why this patchset is on hold.
> To be concrete, the patch is not passed the review because of:
> 1. Bad gc design which I want to fix first, and I already answered why your 
> approach to fix it is not even working. Yes, you could not / did not want to 
> object.

What is wrong with GC and how exactly do you want to "fix" it?

-- 
Konstantin Osipov, Moscow, Russia