From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp20.mail.ru (smtp20.mail.ru [94.100.179.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 27A6C40F3AE for ; Sun, 5 Jul 2020 05:10:56 +0300 (MSK) Date: Sun, 5 Jul 2020 05:10:05 +0300 From: Alexander Turenko Message-ID: <20200705021005.tobk5dor4gg4dhmq@tkn_work_nb> References: <20200701001544.wxx275pojfj3su5o@tkn_work_nb> <2C0F8BEA-3419-4794-B17A-7BF7AFFF9E0C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2C0F8BEA-3419-4794-B17A-7BF7AFFF9E0C@gmail.com> Subject: Re: [Tarantool-patches] [PATCH 2/2] feedback: collect db engines and index features List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?0JjQu9GM0Y8g0JrQvtC90Y7RhdC+0LI=?= Cc: Oleg Babin , tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy LGTM. > > You all know it, but I cannot keep myself from saying again that I'm not > > fan on the idea of the built-in/enabled-by-default reporting tool. > > Especially when it is desined in the way that a user don't have a > > guarantee that its IP address is not collected. It is not in the > > opensource spirit and is not kindly to our users (to ones who care about > > privacy). > > > > I understand why the organization need it: it give some view on > > community -- what is useful and what is not. It may help when we, say, > > prioritize problems. But this fact does not change anything: garthering > > IP addresses and some information without expicit agreement does not > > become a friendly action. > > > > And while we're on the topic, there was the idea from Mons that it would > > feel more comfortable if we would offer something useful for a user > > together with the reporting tool: say, provide information about > > critical / security problems in a running version if it is affected. Or > > feed news about important updates in functionality that is relevant for > > a particular application. I would add from myself that this way the > > reporting tool not even necessarily must be enabled default to be useful > > for us: there is a motivation to enable it. Win-win. Collect only from > > ones who explicitly said that is okay with it. > > > > We also can structurize and improve our documentation and see what > > topics are more popular and what are less. Collect download statistics > > from repositories, rocks and git clones. Here a user explicitly asked an > > action with a remote server and (s)he most likely know that the remote > > server may count it. > > You also stated your concerns about the fact that user's IP may be > tracked and it’s not good practice in open source community. It sounds > valid to me. But I don’t understand how this patch is related to these > concerns. It does not add IP tracking feature, nor the first feedback > daemon version does. This problem should have been arisen when adding > feedback daemon in the first place. If it happen to be noticed now, > after feedback daemon have been merged, a possibility of ip tracking > may be considered as a bug. Personally, I don’t have an idea, how to > solve it in tarantool. It must be some kind of trusted external > service which guarantees to hide original IP address, but I don’t know > such yet. I believe the best way is to start a discussion in GitHub > issues and gather peoples opinions on this. > > Another question you bringing up is the design of feedback tool. You > are saying we may want to rethink goals of the feedback tool (you are > naming it a reporting tool) so a user can benefit from it too. This is > fine idea but it is also a more broader topic to discuss and goes > beyond of this patch changes. I don’t see this patch somehow > interferes with you ideas. Of course, it is not about your patch. Just grumbling around the feedback daemon.