From owner-freebsd-fcp@freebsd.org Thu Aug 29 23:35:44 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 4D364E29B4 for ; Thu, 29 Aug 2019 23:35:44 +0000 (UTC) (envelope-from wlosh@bsdimp.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 46KJrc0jdRz4K6d for ; Thu, 29 Aug 2019 23:35:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 168A5E29B2; Thu, 29 Aug 2019 23:35:44 +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 154A8E29B1 for ; Thu, 29 Aug 2019 23:35:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46KJrb1st5z4K6b for ; Thu, 29 Aug 2019 23:35:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82d.google.com with SMTP id z4so5737920qtc.3 for ; Thu, 29 Aug 2019 16:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OuE5G/e6FXGMIkJBV8BP3Wk+5bkDJcfztwL1SvRTBzw=; b=wy+1S0BELR6E4b2udOu2XvcXrdWNJlpPtozUulVNWd7KlACMl7CaLkBeItIVxb68II J51mSc1MSKClJswNZUDjrXNWenBhTYRcAQsqWao8hU98dQFaQPeY2O9yActusBOKL0d+ CvtiLdJ2bN1MfX+UvjSxA+0SCoL3lvu016hphgRl7+Qu1H0hqkeVLWdEI8Mt3x7/O0/V dHYxR/ZGHfNjjsyaBDKp34+PWfs/WGTM1NZrAh6JT7CusNGkOlRBsh2AmJI1bIxz5OzZ pcq9LmIR5T9iAdOsT5ykP1QyIBk/qsyBjPwJmkeXod5F9FlKUBpXkssi66vwm9hwrbno onhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OuE5G/e6FXGMIkJBV8BP3Wk+5bkDJcfztwL1SvRTBzw=; b=OG9Y0hOIDEJIc17nqxgHWE2ZfxGf6X9vi0YPtHkVRhF321X3pK03n6kDuj6Bm6QJdb +0e/Pu8dSFcEuuLr8IVEFF9oAGEfjA0NseeDlRCMKY58eiXfeJ1Rm+jr9pZ8VYmOzi+c 6p7HVNOZQ8hp1DBCj6BH5c5+d5lVcwa1Of3Jv5DWfPjb+TBiWXMqWY/OxEHTeWFG/olc zIzBMimTg9I4nq7ZxyXG+0Admv7072AB9ZQMEnJRrpQNE4GImC4QtlGQmtIMZpYMAuTf SZmw4AaIMT1XX8sz8n7D6wozrX8ARUU37+KgWs3bM/pSkZ46Pf0nYmVHZI2OqE865sVZ eKLA== X-Gm-Message-State: APjAAAWr685Gi81ew6ydblZ8cBTGnxHEfzJEi7oP0pmFhntL+YGOxdYZ HoJG6ZXqXcnuHnQ/t0EWiRJnj9Ez18qip1X6UwD/+A== X-Google-Smtp-Source: APXvYqzTMPTj69Ol2cCMDvT0Szma2ouUiUxKeSVLtqMCIutdNKm+dZxP09Xg8gGHjgbA8zLtCU++I6+o/7ECcIFRycQ= X-Received: by 2002:ac8:4602:: with SMTP id p2mr12594446qtn.291.1567121741918; Thu, 29 Aug 2019 16:35:41 -0700 (PDT) MIME-Version: 1.0 References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Thu, 29 Aug 2019 17:35:29 -0600 Message-ID: Subject: Re: FCP 20190401-ci_policy: CI policy To: Ed Maste Cc: FreeBSD Hackers , fcp@freebsd.org X-Rspamd-Queue-Id: 46KJrb1st5z4K6b X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=wy+1S0BE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[fcp@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; RCVD_IN_DNSWL_NONE(0.00)[d.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.92)[ip: (-9.40), ipnet: 2607:f8b0::/32(-2.84), asn: 15169(-2.32), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: , X-List-Received-Date: Thu, 29 Aug 2019 23:35:44 -0000 On Thu, Aug 29, 2019, 5:27 PM Ed Maste wrote: > On Thu, 29 Aug 2019 at 17:32, Warner Losh wrote: > > > > In the past, if someone had any follow on work at all in their tree, the > > reversion would be quite disruptive to that work. > > 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. I agree that in the case where the fix is straightforward it's > sensible, and in line with community norms, to just commit it. But in > the case that a regression was introduced by a committed change, > modern tools facilitate reverting and replaying changes without a lot > of effort. > 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. > 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.... > > Note that this isn't at all the issue under discussion in the FCP, > which refers to issues that have already been detected by CI. For > example, a commit which means amd64 panics on boot. Reverting quickly > is a benefit in this sort of case found by CI precisely so that we > don't end up with other changes on top that are difficult to unwind. > 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... Warner >