From owner-freebsd-hackers@freebsd.org Thu Aug 29 23:27:21 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 002E5E260A; Thu, 29 Aug 2019 23:27:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 46KJfw1NcJz4JdM; Thu, 29 Aug 2019 23:27:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id d25so7881750iob.6; Thu, 29 Aug 2019 16:27:19 -0700 (PDT) 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=dEoLdEVaF4XHeFHQy6IytzlYnAzvIf+XzwOID05rIfA=; b=bjwIB44oeNBMH3yjASjJOu8URI39+yfVaWR1SsIwmWEn1nUw182IkP4ewOzu2HRVB9 BIsq4jK5w1Xw4Vc7bPQacrQMBay6ZrhMmbxK+2ij7roeDEm7laC9pT18eBZRW5fVDvz6 VsGM3LOorT8Qd8jzbVdkJluojUrRpnpseal/Jjk0cNWXWe+1VgFYkUR6exfv6e9HN5By MYW9OMsmYXrC2qJbjHMdMScXhQWtMoKnjuAY4xvOsZgwbfYE+RdN5HLogvo2o0gOWY83 fxgY6UylkJNAeHde/7gOQ5mRcM3QElv/hPVYqvjeoXWa7DaTXGfWFKkO1eQ0iNpVbMHp QJgA== X-Gm-Message-State: APjAAAXsk4190DjJ2e8DebDQqFa61WkqcxT/J3hhEPqLjhrrv4SuSn3p oI4K1CKgr3/EAPv1kImQCy0Tyj4nf3rt8jrPkcIulw== X-Google-Smtp-Source: APXvYqxvZ6DCuJBCeNxR3auFNov3NTAXDIXQSfdLVHpJMJbfWMIlCwjamuyGu/b6KnJ/AMQIG/TxBaSxbf/Noi5dYi4= X-Received: by 2002:a02:37c6:: with SMTP id r189mr13535732jar.118.1567121238698; Thu, 29 Aug 2019 16:27:18 -0700 (PDT) MIME-Version: 1.0 References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> In-Reply-To: From: Ed Maste Date: Thu, 29 Aug 2019 19:27:01 -0400 Message-ID: Subject: Re: FCP 20190401-ci_policy: CI policy To: Warner Losh Cc: FreeBSD Hackers , fcp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46KJfw1NcJz4JdM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; RCVD_IN_DNSWL_NONE(0.00)[50.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.55)[ip: (-7.04), ipnet: 209.85.128.0/17(-3.34), asn: 15169(-2.32), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 29 Aug 2019 23:27:21 -0000 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. 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. > 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.