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

[Konstantin Osipov]

* Georgy Kirichenko <georgy at 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.

>  > 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. 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.

-- 
Konstantin Osipov, Moscow, Russia