From owner-svn-src-head@freebsd.org Sat Dec 1 03:15:05 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32787115A369; Sat, 1 Dec 2018 03:15:05 +0000 (UTC) (envelope-from eugen@freebsd.org) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA31C84F09; Sat, 1 Dec 2018 03:15:04 +0000 (UTC) (envelope-from eugen@freebsd.org) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id wB13Ev8e032907 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Dec 2018 04:14:58 +0100 (CET) (envelope-from eugen@freebsd.org) X-Envelope-From: eugen@freebsd.org X-Envelope-To: cem@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id wB13EuY0011932 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Dec 2018 10:14:56 +0700 (+07) (envelope-from eugen@freebsd.org) Subject: Re: svn commit: r341352 - head/usr.sbin/trim To: cem@freebsd.org References: <201811302157.wAULv2iH057184@repo.freebsd.org> Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Eugene Grosbein Message-ID: <13bec879-3cf5-3f9b-58a3-47f7405e5f77@freebsd.org> Date: Sat, 1 Dec 2018 10:14:44 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: BA31C84F09 X-Spamd-Result: default: False [-0.33 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.40)[-0.401,0]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; NEURAL_SPAM_SHORT(0.29)[0.292,0]; NEURAL_HAM_LONG(-0.22)[-0.217,0] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2018 03:15:05 -0000 01.12.2018 9:34, Conrad Meyer wrote: > Generally when a committer puts a patch on phabricator, they'll commit > it when they're ready. I think this is wrong behaviour of the Phabricator to auto-close a differential just because some singe commit referred to it. It was not meant to be closed for now and I've just re-opened the differential. > In particular this patch hadn't actually been > approved by any reviewers yet and review discussion was still active. Is it possible to add hackers@ audience to reviewers list? I do not see people discussing the topic adding themselves and it would be wrong to force them. > As far as I can tell, imp@ hadn't indicated he wasn't going to commit > his patch himself. Parts of changes that have consensus were committed. Why is it bad? > I'd love to be imagining things, but it seems like > the general trend is you consistently fail to follow basic etiquette > and consistently ignore review and concerns. > > This time around you definitely don't have the excuse of phabricator > being silent for months — the review hadn't seen any 24h period of > inactivity since its creation. > > I was tentatively ok with trim staying in based on imp@ taking charge > of cleaning up the deficiencies, but you've gone around imp@ and > ignored me completely. This is untrue: I committed some changes requested by you and imp. > Please back out trim and consider taking a few days off. The way trim > has entered the tree is just not how we do things as a project. I > think there's universal consensus that we want a tool that does what > trim does in base; there's some bikeshedding about whether it should > live in dd or not (it shouldn't); but rest assured, it will go in in > some form. My ask is that it to go in the right way, instead of the > total mess it has so been so far. I have not seen universal consensus about backing it out and I disagree that it is "total mess". The code is small, clean and works. But if you insist, feel free to remove it.