+ 2021-02-06 0:50 GMT+03:00, Maxim Muzafarov <mmu...@apache.org>: > Folks, > > Since the vote of removing MVCC API [1] completes successfully can we > disable the MVCC suites? > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/RESULT-VOTE-Removing-MVCC-public-API-tp50705.html > > On Mon, 7 Dec 2020 at 09:38, Ivan Pavlukhin <vololo...@gmail.com> wrote: >> >> Hi Igniters, >> >> > The feature is not production-ready, and I don't think it is used at >> > all. >> >> Unfortunately, we cannot be sure that the feature is not used at all. >> I recall some threads on user list about it. >> >> I understand concerns of those who want to get rid of MVCC. And the >> feature seems to be abandoned today and only increases development >> complexity. So, I think that cleaning up MVCC code is a good idea if >> there is no benefit for the developer community to maintain it today. >> But I suppose such decision should be properly communicated with the >> user community. >> >> 2020-12-02 18:31 GMT+03:00, Alex Plehanov <plehanov.a...@gmail.com>: >> > -1 for disabling test without removing the code. Current tests give us >> > at >> > least "something works" status for the feature available to users, >> > without >> > these tests, we can smoothly move to "totally unusable" status. >> > Complete removal of MVCC can be resource-consuming, but if we want to >> > disable tests at least we should hide the public MVCC API or totally >> > prohibit MVCC usage. Also, it can't be done in 2.x release due to >> > backward >> > compatibility. >> > >> > ср, 2 дек. 2020 г. в 17:28, Nikolay Izhikov <nizhi...@apache.org>: >> > >> >> > Yes, it can be done. However, I don't think that we will get an >> >> agreement on that >> >> >> >> Let’s give it a try and see what happens :) >> >> >> >> >> >> > 2 дек. 2020 г., в 17:23, Вячеслав Коптилин >> >> > <slava.kopti...@gmail.com> >> >> написал(а): >> >> > >> >> >> Can you start the vote? >> >> > Yes, it can be done. However, I don't think that we will get an >> >> > agreement >> >> > on that (I just recall the previous discussion). >> >> > And so, we will not remove the MVCC code; on the other hand, nobody >> >> > will >> >> > support it in the future. We already at this point. This is just my >> >> humble >> >> > opinion. >> >> > >> >> >> It's strange turning off here the whole MVCC tests just because >> >> something >> >> > in the master branch was broken when in the second thread >> >> > On one side, it looks weird, I agree. On the other hand, nobody >> >> > cares >> >> about >> >> > that and wants to fix tests. This is a stalemate, I think. >> >> > >> >> > Thanks, >> >> > S. >> >> > >> >> > ср, 2 дек. 2020 г. в 16:47, Maxim Muzafarov <mmu...@apache.org>: >> >> > >> >> >> Slava, >> >> >> >> >> >> Can you start the vote? >> >> >> >> >> >> It's strange turning off here the whole MVCC tests just because >> >> >> something in the master branch was broken when in the second thread >> >> >> Community decide to continue MVCC support. Let's start the vote and >> >> >> see what happens. >> >> >> >> >> >> On Wed, 2 Dec 2020 at 16:39, Вячеслав Коптилин < >> >> slava.kopti...@gmail.com> >> >> >> wrote: >> >> >>> >> >> >>>> It will be even worse if our users will face NPE or things like >> >> >>>> that >> >> >> in >> >> >>> the basic MVCC scenarios just because we don’t tests it. >> >> >>> The feature is not production-ready, and I don't think it is used >> >> >>> at >> >> all. >> >> >>> Moreover, MVCC Cache 7, 8, 8, MVCC PDS 1, 2, 4 are already broken >> >> >>> (execution timeouts, flaky test, etc) and I haven't seen anyone >> >> >>> who >> >> would >> >> >>> like to fix this. >> >> >>> Why should we waste every contributor's time? IMHO, MVCC suites >> >> >>> are >> >> >> useless >> >> >>> and everyone just pushes "re-run possible blockers" button and >> >> >>> doesn't >> >> >> care >> >> >>> about MVCC tests at all. >> >> >>> >> >> >>> Thanks, >> >> >>> S. >> >> >>> >> >> >>> ср, 2 дек. 2020 г. в 16:01, Nikolay Izhikov <nizhi...@apache.org>: >> >> >>> >> >> >>>>> I think test suites can be disabled even today >> >> >>>> >> >> >>>> I’m -1 to disable tests without complete removal. >> >> >>>> It will be even worse if our users will face NPE or things like >> >> >>>> that >> >> in >> >> >>>> the basic MVCC scenarios just because we don’t tests it. >> >> >>>> >> >> >>>> >> >> >>>>> 2 дек. 2020 г., в 15:50, Вячеслав Коптилин >> >> >>>>> <slava.kopti...@gmail.com >> >> >>> >> >> >>>> написал(а): >> >> >>>>> >> >> >>>>> Hi Nikolay, >> >> >>>>> >> >> >>>>>> Why do we need feature in the project that not even tested >> >> >> regularly? >> >> >>>>> Fair enough. However, I am not an expert in this area (MVCC and >> >> >> SQL), so >> >> >>>> I >> >> >>>>> cannot say how much effort it will take. >> >> >>>>> I would say that the opinion of the rest of the community is >> >> >>>>> needed >> >> >> here. >> >> >>>>> >> >> >>>>> Anyway, I think test suites can be disabled even today, while >> >> >>>>> the >> >> >> fate of >> >> >>>>> the MVCC feature can be (and should be) discussed separately. >> >> >>>>> What do you think? >> >> >>>>> >> >> >>>>> Thanks, >> >> >>>>> S. >> >> >>>>> >> >> >>>>> ср, 2 дек. 2020 г. в 15:38, Nikolay Izhikov >> >> >>>>> <nizhi...@apache.org>: >> >> >>>>> >> >> >>>>>> Hello, Slava! >> >> >>>>>> >> >> >>>>>> Yes, this topic comes to the top from time to time :) >> >> >>>>>> >> >> >>>>>>> . I just want to save the time required for getting TCBot's >> >> >>>>>>> visa >> >> >> and TC >> >> >>>>>> resources. >> >> >>>>>> >> >> >>>>>> Why do we need feature in the project that not even tested >> >> >> regularly? >> >> >>>>>> >> >> >>>>>>> 2 дек. 2020 г., в 15:36, Вячеслав Коптилин < >> >> >> slava.kopti...@gmail.com> >> >> >>>>>> написал(а): >> >> >>>>>>> >> >> >>>>>>> Hello Nikolay, >> >> >>>>>>> >> >> >>>>>>>> +1 to vote for complete MVCC removal. >> >> >>>>>>> It has already been discussed here [1] and, unfortunately, I >> >> >>>>>>> have >> >> >> not >> >> >>>>>> seen >> >> >>>>>>> an agreement on that. >> >> >>>>>>> >> >> >>>>>>> [1] >> >> >>>>>>> >> >> >>>>>> >> >> >>>> >> >> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> Thanks, >> >> >>>>>>> S. >> >> >>>>>>> >> >> >>>>>>> ср, 2 дек. 2020 г. в 13:05, Nikolay Izhikov >> >> >>>>>>> <nizhi...@apache.org>: >> >> >>>>>>> >> >> >>>>>>>> +1 to vote for complete MVCC removal. >> >> >>>>>>>> >> >> >>>>>>>> MVCC is a great feature but we should implement it as a >> >> >> first-class >> >> >>>>>>>> feature and not «something that pretends to be working» >> >> >>>>>>>> >> >> >>>>>>>>> 2 дек. 2020 г., в 12:53, Maxim Muzafarov <mmu...@apache.org> >> >> >>>>>> написал(а): >> >> >>>>>>>>> >> >> >>>>>>>>> Hello Slava, >> >> >>>>>>>>> >> >> >>>>>>>>> I think we should vote for MVCC termination of support. If >> >> >>>>>>>>> the >> >> >> vote >> >> >>>>>>>>> will be successful than remove it from the source code and >> >> >> disable >> >> >>>>>>>>> MVCC suites. >> >> >>>>>>>>> >> >> >>>>>>>>> Only disabling tests from MVCC sounds not good. >> >> >>>>>>>>> >> >> >>>>>>>>> On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин < >> >> >>>>>> slava.kopti...@gmail.com> >> >> >>>>>>>> wrote: >> >> >>>>>>>>>> >> >> >>>>>>>>>> Hello Igniters, >> >> >>>>>>>>>> >> >> >>>>>>>>>> It looks like there is no activity related to maintaining >> >> >>>>>>>>>> or >> >> >>>>>> developing >> >> >>>>>>>> the >> >> >>>>>>>>>> MVCC feature. >> >> >>>>>>>>>> So, I see no reason to waste TeamCity resources. I propose >> >> >>>>>>>>>> to >> >> >>>> disable >> >> >>>>>>>> the >> >> >>>>>>>>>> corresponding test suites. >> >> >>>>>>>>>> This has already been discussed here as well [1]. >> >> >>>>>>>>>> >> >> >>>>>>>>>> [1] >> >> >>>>>>>>>> >> >> >>>>>>>> >> >> >>>>>> >> >> >>>> >> >> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html >> >> >>>>>>>>>> >> >> >>>>>>>>>> Thanks, >> >> >>>>>>>>>> S. >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>> >> >> >>>> >> >> >> >> >> >> >> >> > >> >> >> -- >> >> Best regards, >> Ivan Pavlukhin >
-- Best regards, Ivan Pavlukhin
