Re: [Tarantool-patches] [PATCH] Trigger on vclock change

[Georgy Kirichenko <kirichenkoga@gmail.com>]

On Saturday, November 16, 2019 1:37:55 PM MSK Konstantin Osipov wrote:
> * Georgy Kirichenko <georgy@tarantool.org> [19/11/15 22:59]:
> > > I gave earlier in this thread concrete examples how active-active
> > 
> > You made a mistake again. My approach is not about
> > active-active. I did not ever claim that my patch will allow active-active
> > (because we do not still have a transaction manager). When I said that any
> > instance is able to commit I mean that any replica, which sees a majority,
> > able to finalize a transaction (commit it) even if the transaction
> > initiator is dead.
> 
> Fine, that might work - given the vector clock this how it will
> naturally work in most cases. Too bad you kept it a secret until now.
> 
> > > won't work. It didn't take me long. You chose to respond back with
> > > some vague claims and promises of magic.
> > 
> > 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.
> > 
> > > 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.
> 
> Ehm, where's the link? Or tarantool is now closed source? Sharing
> it publicly would have allowed me collaborate  - which you seems to
> intentionally want to avoid.
There is no link because this is just a research which would be shared when it 
have some proofs. I definitely do not want to pollute the public mail list. And 
having many-turns responded RFCs is not good for communication as it erodes 
the initial topic.
> 
> >  > 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.
> > 2. Vlad's comment about comments and naming. Please tell me how a miracle
> > RFC could fix this issue (Yes, I am not very accurate with comments and
> > texts) 3. Vlad comment about dynamic array allocation which I want to
> > respond in the next version. I would like to repeat, I do not want to
> > sent it until the first point will not be fixed.
> > 4. Vlad's comments about some mess in my code (xlog_buf_begin and
> > friends).
> > They are already fixed but not shared because of the first point. And
> > there is no way how a RFC could prevent it.
> > 
> > > All this suggests that the patch by Maria is simply not worth it.
> > 
> > All this suggest that you have no clue how the patch would work in the
> > future, seriously.
> 
> Well, this is not because of any lack of intent on my part. Going
> back to the patch, it doesn't look good so far.
Sorry, but you have  written: "This is well designed in my view" which I 
accepted with proud. The only you complain was about the garbage collection. 
And you did not respond anything to my last patch.
> If you wanted to
> change my opinion, the best course of action is to use technical
> arguments (and RFC is the best way for it), not some ungrounded
> claims about better processes or how to best contribute to an open
> source project.
> 
> > > Whatever it is needed for may never happen - and even if it
> > > happens, it is most likely the wrong thing to do.