From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 26E596EC5E; Sun, 11 Apr 2021 17:15:12 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 26E596EC5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618150512; bh=LbwwN7u07n0dv8Rl4vR4cMLuRaznGJqv9tmqozj8Udo=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=NQ6r2WTqN8iUzFtU7ZxTuyR9Qx/7J6B/BpnGd5xnhwcRdAzqHVXsSowRRfGhIN5uJ wVyCs5cRIjxpVYZwtikF/NH4sq6PsdcpR+RvSVDQqKh8Z1dV27Xy1fI49qG8Ne2vyy cYvZ8bIN5lrMTJ2Edm1lv5q3KTkf673BWZ1jxuJs= Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 EBB1B6EC5E for ; Sun, 11 Apr 2021 17:15:09 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EBB1B6EC5E Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1lVark-0000vJ-HJ; Sun, 11 Apr 2021 17:15:09 +0300 To: Serge Petrenko , alexander.turenko@tarantool.org Cc: tarantool-patches@dev.tarantool.org References: Message-ID: Date: Sun, 11 Apr 2021 16:15:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E74807BAE725B9AE625DE765B0E193B5B7687182A05F538085040557463180E8658BAE8AD6B2DDB7638A64DBBDA5F53C5954B4ECD2687B6D31EAB X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE79683A3C835791080EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637F97367C191A19EB28638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B2A3B650E3DA71F3234429DB2E338FDA8440B83DF1158C6122D2E47CDBA5A96583C09775C1D3CA48CFCF36E64A7E3F8E58117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE709B92020B71E24959FA2833FD35BB23DF004C906525384302BEBFE083D3B9BA73A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E73542F54486E6D6388DC4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A54E028A1FD9C203A5AA7C9D2F40FBCF6ECEEC36D7D9E56729D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34D6AC337C1E637B8AB38BA70ED1A69F52BB42523A4ACB19F98A1DA8D2EDAC660FC05503C9659DAEAA1D7E09C32AA3244C88A59032C2F39533A12BFDB2A74EB0A4B4DF56057A86259FFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojyKKJYJ15DtL/sY0aa/YyfA== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822B41217AC31D95EEF97A163808BE61F6E3841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v2 0/5] send feedback on start and on key events X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thanks for the patchset, Sergey! Technically the patchset looks bearable. Below text is for the people who forced us to do this ticket. Disclaimer: this is not toxic. I mostly just ask questions and express my opinion. I don't like the patch. The hack to workaround some CI issues with a sleep, and the behaviour we introduce on the whole. I don't think creation of a first space/index makes any sense to track. The reason about "going through a tutorial" is a very weak argument. Spaces are created not only as a part of a tutorial obviously. And I see no other reason for sending these "events". This rant is for Mons, Artur, and whoever else pushed sending of that useless information and introduction of a **known bug** which we hack with 10s sleep. I bet they have no idea how to really use it **exactly**, not in some abstract way they will try to figure out later, and they just wanted to send "something" to close some story-points. We on purpose **push buggy code** only to send these feedback events we don't know what to do with. Here is what I see in the issue: In order for us to assess the real situation for the product, it is necessary to send feedback from the product immediately after the launch and after the key actions are completed. How the hell is it related to a "real situation for the product"? How is it "necessary"? What was wrong with the feedback we have now? How are the instances working less than 1 hour are so important? And why do you need to know exactly when a first space/index was created? Well, even if we need it, we could remember the timestamps and send them with the next regular report. Another cite: If Tarantool was installed using a script from the Download page, then you need to send feedback immediately and further after the following events are completed: ... The rest of Tarantool that were downloaded outside of the Download page does not contain a special meta-file and should be considered as internal usage and no feedback sent from them. These are usually CI instances. What is that "metafile"? We send the feedback anyway regardless of some metafile in this patch, and from where the executable file was downloaded. Which again renders this "feature" absolutely useless. Besides, creation of a first index and space won't cover instances which don't create any indexes and spaces. For example, vshard routers. Additionally, implementation of this code stole time from the scaling team on writing the code, doing the reviews, doing the review fixes. How is it even related to the scaling team at all? Why was it so urgent and more important than finishing a fix for a serious bug in the synchronous replication? I would propose Artur to send a PR for that next time. Tickets like that should go to the wishlist right away, instead of the known crashes and optimizations. I hope we will drop these feedback events in the future when will realize it does not help anyhow with a problem which can't even be properly formulated, and because it introduces a bug we don't know for sure why is happening, and how can be fixed except the 10s sleep hack.