From owner-freebsd-hackers@freebsd.org Fri Aug 30 02:01:12 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 7E4A3E63F9; Fri, 30 Aug 2019 02:01:12 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (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 46KN4Q2qRvz4WFn; Fri, 30 Aug 2019 02:01:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3WDqi33ZosAGk3WDritoMk; Thu, 29 Aug 2019 20:01:08 -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=FmdZ9Uzk2mMA:10 a=7Qk2ozbKAAAA:8 a=iKhvJSA4AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=GD4Lj2ni4_LfeXk_s_gA:9 a=CjuIK1q_8ugA:10 a=HNhVPpsFFhwA:10 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 EE3C3754; Thu, 29 Aug 2019 19:01:04 -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 x7U214i0086083; Thu, 29 Aug 2019 19:01:04 -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 x7U214qn086080; Thu, 29 Aug 2019 19:01:04 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201908300201.x7U214qn086080@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: Warner Losh cc: "Rodney W. Grimes" , Ian Lepore , FreeBSD Hackers , Marcelo Araujo , fcp@freebsd.org, Konstantin Belousov , Li-Wen Hsu , Kristof Provost Subject: Re: FCP 20190401-ci_policy: CI policy In-reply-to: References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> Comments: In-reply-to Warner Losh message dated "Thu, 29 Aug 2019 15:32:17 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Aug 2019 19:01:04 -0700 X-CMAE-Envelope: MS4wfCI6Bkf8Ut4g4MzXQp1XYy6ido4ceg6QBsesfQUY+aMQgaACX9ydSCxK/0xBNpj1JgJNpgdrqFAlnwpWR7bWWfmMt6xAWe1lYac7jxAcBPVcRzjMjeSL 5y8ItgPdDptRmOG4F6GNUBNBbe+9YykOS4laGW8S7DggEwYagGaoeFS998kXhOCYHH+6OcJnbRS+LPaZLzF1Hd/N/qnAKkIBtGsJraoGjVKz2PhQ1nJJSCNG ncuXy6NRannaA/DQivkgak67BVWVKBnrCu1RuV1nzvMpz/XmIzVsJni6ja5x4dnyfoVuX2uPewpprvjKG5jGOVHQep68RHe9FPzLYZzezDFQC4hiOVOM7r9f yW7AxOPYOweVgafdCJap9it7RXBYgYEP/GvV2qOhpaV0EPhcIOk= X-Rspamd-Queue-Id: 46KN4Q2qRvz4WFn 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.13) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-5.03 / 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.952,0]; RCVD_IN_DNSWL_NONE(0.00)[13.134.59.64.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[9]; 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.48)[ip: (-6.76), ipnet: 64.59.128.0/20(-3.13), asn: 6327(-2.43), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] 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 02:01:12 -0000 In message , 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 search > >> 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 the > >> > > > 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 and > >> > > > 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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.