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 6291E469719 for ; Fri, 21 Feb 2020 10:12:30 +0300 (MSK) Received: by mail-lf1-f67.google.com with SMTP id b15so719742lfc.4 for ; Thu, 20 Feb 2020 23:12:30 -0800 (PST) Date: Fri, 21 Feb 2020 10:12:28 +0300 From: Konstantin Osipov Message-ID: <20200221071228.GA15098@atlas> References: <6b8602a297876492179b695f317e809bd425af79.1582209853.git.imun@tarantool.org> <20200220180341.GA31973@atlas> <20200220204820.GF404@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200220204820.GF404@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] build: disable LUAJIT_ENABLE_PAIRSMM List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy * Igor Munkin [20/02/20 23:57]: > > This is pathetic. Don't you realize that once a version is > > released and declared stable, it's a legacy you have to live with? > > As we announced the patch was applied by mistake. If you found the place > we missed, please show it. If you want to complain and blame someone, > feel free to choose me, since I initially proposed this amiss and > breaking solution in #4560[1]. Unfortunately this doesn't make the > situation easier for both of us. It's not a blame in this case, I simply reply to a commit I have a chance to reply to. The revert commit went in without any discussion on the list and without a code review. I looked at 4560 now and realized that the incompatible change was added to 1.10 as well. Ugh. I guess then it's definitely correct to revert it there... so I withdraw my suggestion to keep it. > > Now you have *3* broken behaviours to support, instead of just > > two. Some people will still use a version which they believe is > > stable, and encounter strange failures. > > I'm bad in math here, since I see only two behaviours: the old one and > the broken one. Three would be if we settle the issue and save the > introduced behaviour the way you proposed below. Then there will be: > * working Tarantool w/o __pairs > * broken Tarantool w/ __pairs > * working Tarantool w/ __pairs Well, I simply count before-during-after, I'm not that sophisticated here. > > Eventually you'll have to enable 5.2 compatibility anyway (are you > > going to stay with 5.1 forever??), and then break it again. > > I can't answer it now. You are the visionary, I'm even not a mainainer. 1) Nobody is a maintainer, even the people who push patches. Maintenance in particular includes assuming personal public responsibility in the community for one's work. Maintenance also is not something assigned by a management, it has to be supported by contributions to the code base and recognized by peers. 2) If Tarantool sticks to the release policy, there won't be any other window to introduce __pairs till 3.x, which is still a few years ahead. This is what drives me crazy - I thought you only pushed it to 2.x and in that case the patch definitely should have stayed. > We discussed it in tg chat some time ago but I haven't been answered the > question about your vision of this question. I welcome you to proceed > the discussion and you can choose the most convenient way for it. > > luafun is a builtin and table.deepcopy are builtins. What prevented you from fixing them > > instead? > > That would fix 99% of cases. > > I see no guarantees here, and guess you can provide nothing. I agree, but I trust our test coverage. -- Konstantin Osipov, Moscow, Russia