From owner-freebsd-hackers@freebsd.org Fri Aug 30 07:25:05 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1EEFAC50BC; Fri, 30 Aug 2019 07:25:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46KWG8602Sz3HPK; Fri, 30 Aug 2019 07:25:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7U7Ou0a047434 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 30 Aug 2019 10:24:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7U7Ou0a047434 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7U7OtPu047433; Fri, 30 Aug 2019 10:24:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Aug 2019 10:24:55 +0300 From: Konstantin Belousov To: Ed Maste Cc: Warner Losh , FreeBSD Hackers , fcp@freebsd.org Subject: Re: FCP 20190401-ci_policy: CI policy Message-ID: <20190830072455.GD71821@kib.kiev.ua> References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46KWG8602Sz3HPK X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.920,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:25:05 -0000 On Thu, Aug 29, 2019 at 07:44:59PM -0400, Ed Maste wrote: > >> This sounds more like a problem with the tooling than an argument > >> against reverting though. > > > > We live in a subversion universe for the moment, so you have to view it through that lens. > > Fair enough, right now the policy needs to accommodate the reality of > the tools we're using today. > > Perhaps it's a failure of imagination on my part but I have trouble > seeing how a revert would lead to losing work - could you give an > example? If you have a committed change that is the precursor for later series, and this series is not yet committed. Then rebase or merge of the master with the base change reverted causes much trouble. > > > Sometimes yes, sometimes no. Even with git svn, there is a cost associated with it. The level of effort is not zero. Especially when one pushes several interrelated changes at once. If the first of these caused an issue on gcc, say, often the cost is too high to revert the whole chain. It's a lot easier to put in a fix and move on. > > The level of effort imposed on other users while the tree is broken is > not zero, either. Certainly if it's possible to commit a fix and move > forward that's the approach favoured by community norms. > > > It's a fair example for why a simpleminded approach will create more friction than the current system. And there is a need for caution in expanding the logic beyond all but the most recent changes... > > The point of the FCP is to facilitate the revert while the change is > (among the) most recent, precisely so that additional changes don't > build on it. Also, I have to admit publically, that my changes were blamed by CI so many times, when they had nothing to do with the breakage. I forwarded such mails to ci@ regularly, then stopped doing that. Also, I believe that imposing requirements on committers to not offend CI is not fair if committers cannot _easily_ verify that the change does not. Give us a way to e.g. mail pgp-signed message to ci-check@ and get the reply 'ok/fail' in reasonable time, or a button on phab to get the same response. Even if I bother to recreate CI env locally (I do not), races are different on the CI machines.