From owner-freebsd-fcp@freebsd.org Mon Sep 2 06:57:17 2019 Return-Path: Delivered-To: freebsd-fcp@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 8CF1ED38BE for ; Mon, 2 Sep 2019 06:57:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46MLVj1ZB1z4L8t for ; Mon, 2 Sep 2019 06:57:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.nyi.freebsd.org (Postfix) id 35C41D38BC; Mon, 2 Sep 2019 06:57:17 +0000 (UTC) Delivered-To: fcp@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 35746D38BB; Mon, 2 Sep 2019 06:57:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46MLVg6LrCz4L8r; Mon, 2 Sep 2019 06:57:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 4gH0iXs2QsAGk4gH2i1wR3; Mon, 02 Sep 2019 00:57:13 -0600 X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=J70Eh1EUuV4A:10 a=VxmjJ2MpAAAA:8 a=7Qk2ozbKAAAA:8 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=CcuWIOYoXdM3unlOn6gA:9 a=CjuIK1q_8ugA:10 a=FBhmBtCL6EQA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=1lyxoWkJIXJV6VJUPhuM:22 a=odh9cflL3HIXMm4fY7Wr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 1C033A88; Sun, 1 Sep 2019 23:57:09 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x826v8Nn021659; Sun, 1 Sep 2019 23:57:08 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x826v5ot021581; Sun, 1 Sep 2019 23:57:05 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201909020657.x826v5ot021581@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Warner Losh , Ian Lepore , FreeBSD Hackers , "Rodney W. Grimes" , Marcelo Araujo , fcp@freebsd.org, Konstantin Belousov , Li-Wen Hsu , Kristof Provost Subject: Re: FCP 20190401-ci_policy: CI policy In-reply-to: <201908300201.x7U214qn086080@slippy.cwsent.com> References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> <201908300201.x7U214qn086080@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Thu, 29 Aug 2019 19:01:04 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-CMAE-Envelope: MS4wfC9PFhw4adguYH4LsGSztIxJ5WQ0J3hMdJahUxCDMCNzU+XwB9y3ft0CCGngrXHRTgNK5BZHeIWfLauQZBE3VAGRHw/NiuTyi5cwLt7XNr4Ejis3vrH4 SPIU1SBneNlwx1meKZ4v2JGmzTMkOyT2+8Ae5/LbqRj4LsIESWQL6kInbe0DuPWZQryah9+yV+NKhaDjLBD9NfP8oSJl0cxZ6KLN6+KfiCxs3EF1ZWLzIuDY KsYhpzwokUsVImgpJbJEqmsyUEuY3znwrt9a99aTKlR4Z++BXM2e0Q3+48nAoVXPc3Nyx/Zvh8rbhgw8xVHKl+2sUV/gluWedavbIkwoA83AHfMTbCg7HJkp rGtLh4xy3gZqNUfViyTORdnFqIYtl3rdebTATq4vBXII/0Gb0DE= X-Rspamd-Queue-Id: 46MLVg6LrCz4L8r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.951,0]; RCVD_IN_DNSWL_NONE(0.00)[9.134.59.64.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[10]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.39)[ip: (-6.31), ipnet: 64.59.128.0/20(-3.12), asn: 6327(-2.42), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-Mailman-Approved-At: Sun, 13 Oct 2019 15:48:20 +0000 X-BeenThere: freebsd-fcp@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD Community Proposals List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 02 Sep 2019 06:57:17 -0000 X-Original-Date: Sun, 01 Sep 2019 23:57:05 -0700 X-List-Received-Date: Mon, 02 Sep 2019 06:57:17 -0000 In message <201908300201.x7U214qn086080@slippy.cwsent.com>, Cy Schubert writes: > In message om> > , Warner Losh writes: > > On Thu, Aug 29, 2019 at 3:26 PM Warner Losh wrote: > > > > > > > > > > > On Thu, Aug 29, 2019 at 1:05 PM Rodney W. Grimes < > > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > >> (unneeded context removed) > > >> > > >> > > In either scenario we end up reducing test coverage, which means we? > re > > >> > > going to push more bugs towards users. > > >> > > > > >> > > > I totally agree. This is an overly-bureaucratic solution in searc > h > > >> of > > >> > > > a problem. > > >> > > > > > >> > > > If this needs to be addressed at all (and I'm not sure it does), > > >> then > > >> > > > another sentence or two in bullet item 10 in section 18.1 [*] of t > he > > >> > > > committer's guide should be enough. And even then it needn't be > > >> > > > overly-formal and should just mention that if a commit does break > > >> the > > >> > > > build the committer is expected to be responsive to that problem a > nd > > >> > > > the commit might get reverted if they're unresponsive. I don't > > >> think > > >> > > > we need schedules. > > >> > > > > > >> > > I do feel that?s a better argument. We?ve always had a policy of > > >> > > reverting on request (AIUI), so this is more or less trying to be a > > >> > > strong restatement of that, more than a fundamental shift in policy. > > >> > > > > >> > > > >> > We don't have a policy to revert commit, actually revert commit is > > >> > something bad, it is kind of punishment, I have been there, nobody > > >> wants to > > >> > be there. Stop to push this non-sense argument. > > >> > > >> Here in lies one of the fundemental problems, this view by some that > > >> a "revert commit is something bad, it is kind of punishment". That is > > >> not true. Reverts are GREAT things, they allow the tree to be returned > > >> to a known state, usually quicly. The original commit is STILL IN SVN, > > >> and a bad revert can guess what.. be reverted!. > > >> > > >> IMHO the project as a whole needs to overcome its fear of reverts and > > >> start to use them for the great and powerful things that they are. > > >> > > >> This connection of bad and punishment needs to stop, and the sooner > > >> the better. > > >> > > > > > In the past, if someone had any follow on work at all in their tree, the > > reversion would be quite disruptive to that work. Most of the time it's a > > lot easier for me, with a lot less friction, to just fix issues that come > > up after the commit than to revert and prepare a new commit. Sure, it's > > possible, but it can destroy work in extreme cases. *THAT* is why I'm > > firmly in the camp of giving the original committer a shot at fixing things > > because it's much less disruptive to them, and generally we can get a fix > > into the tree faster. It reduces friction and encourages people to fix > > things quickly, imho, to hesitate a little on the revert. Especailly when > > the broken thing is the playstation loader on powerpc that can stay broken > > for the hour or six (or even days) it takes me to figure out why it > > broke... Often things away from the beaten path don't get discovered for > > days or weeks or months, and a reversion then can be extremely disruptive > > if there's other changes layered on top of the offending commit.... > > > > So the whole reversion issue is a lot more complicated than 'oh, it's still > > in svn'. There are real high costs associated with being too quick or > > liberal on the revert and those must be weighed against the damage the bad > > commit is doing.. > > I think that's why we need to define the problem first. > > The justification of the arbitrary numbers of minutes/hours isn't clear. > > I see there are possibly two trains of thought here which need to be > separated. > > 1. A general frustration by some. > > 2. A tool, a solution to a problem, I am unsure if it is related to #1. > > Why do I see this as such? > > The problem statement beings by saying that FreeBSD has a CI system that > performs compiles and runs automated tests. In the next paragraph it says > sometimes changes break compilation... > > This tells me that A) we have a solution which we discuss in B (the > problem). > > To my thinking we need to approach this from: A) we have a problem, maybe > backing it up with some stats some evidence of sorts. Then explore one or > preferably two solutions. Not to be hard on anyone and keeping my emotions > out of it, they way the problem statement is structured reads to me as a > solution looking for a problem. That's not to say we don't have a problem > (nor am I saying we do have a problem either). The problem statement is > structured to a foregone conclusion. > > I'd structure this by stating the problem (paragraph 2 and the bullet > points, though I think the problem needs to be explored a little more), > then discuss some of the timing issues regarding the fixing of the three > types of problems (compile, panic, and regressions, of which tests identify > regressions). > > I'm not saying that there is or isn't a problem but the problem statement > as written doesn't convince me there is a problem. It's leading me to a > conclusion. Thinking much of this week about how I approached this, it was wrong of me to structure this email in this way to convey I wasn't entirely convinced. This was critique and it should not have been. My email was offensive and for that I'm sorry. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.