From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 841BF212B4 for ; Wed, 24 Jul 2019 11:11:51 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taeIubNyml73 for ; Wed, 24 Jul 2019 11:11:51 -0400 (EDT) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id E67A42120E for ; Wed, 24 Jul 2019 11:11:50 -0400 (EDT) Date: Wed, 24 Jul 2019 18:11:48 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH] Output of fiber.info will contain only non-idle fibers Message-ID: <20190724151148.GB31283@atlas> References: <20190723195643.GA18567@atlas> <20190724080009.l37vvopimxjdqs5h@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190724080009.l37vvopimxjdqs5h@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: georgy@tarantool.org * Kirill Yukhin [19/07/24 11:03]: > > * Maria K [19/07/23 21:01]: > > > The output used to be too cluttered due to idle ones. > > > > > > Closes #4235 > > > > @kyukhin, first, please I don't get how does this get scheduled to a > > milestone? How does this follow triage guidelines? > > I won't ever discuss any internal documents publicly, sorry. > I believe this contradicts ethitcs. That is second time you doing > this, please stop. Well, I guess then it is time to make SOP public. How do you expect me to participate in it as a community member if I don't share how the project is run and direction it takes? I've been mentioning this before -- things will have to become more open, including defining the product roadmap and what features get in, if we're to switch to a community driven model. You can't expect one contributor party to drive the roadmap and another merely do the review work. > > > Please don't schedule anything that is not a priority, even if > > it's a noob issue, since it takes time of everyone involved. > > That was a customer request. If you'd like not to review the patch - > feel free to just skip it, we'll find another reviewer. Well, then it has to be well defined- I pointed out obvious issues with this change. PS And no, TTLing reviews is also a wrong idea. One or two bad patches getting in like that and it will be easier for me to fork and cherry-pick changes than provide any reviews and work on a common trunk. -- Konstantin Osipov, Moscow, Russia