From owner-freebsd-hackers@freebsd.org Thu Aug 29 23:45:18 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 BC82FE2DDD; Thu, 29 Aug 2019 23:45:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 46KK3d4fxyz4Klf; Thu, 29 Aug 2019 23:45:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f54.google.com with SMTP id p12so10491877iog.5; Thu, 29 Aug 2019 16:45:17 -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:content-transfer-encoding; bh=0FSmYVskYbBYnGN185uLQL22o1T6D9MYbnRnoxDC67o=; b=YquEtH80LyW3R9CDO7QUZqCKeO5zjbWtVE6YWGMkcLMvlGXBfddG7Ce+fS1VC8IpHw JodIJyadRUhHtAFJijSvkHnoWd5sdUanOgKOQXgcLl0OuBq+nV/uj5DBF4W9xRBOkntF DwabNmKLapTfZQjcoTggiVhJ2VVICHst5+u8CLs7N+GzQb3Kt0TpqjYax8PVD9AzDQ6b yfej53kV8rH/C58O/YA8Nh+seaiLQl8wOAhuH6OPyyxsAyjSZyk3qAlxspwq0FHcNQgn kNjZxfwisDlQAnMgwFJXmPWpzYETFCScG1WizxG7TfU6vTeXH3XAYqno5FCkcJl+M9wa Dy6A== X-Gm-Message-State: APjAAAXgI3f8nh7PU5W2gVGtOtzkyf8JMfrfunKRYvRnxXbtheSaXOjs 7xZgqxAEJmS3X9ytFFnZGNIhcxBX3bhOxAx0exM= X-Google-Smtp-Source: APXvYqxgh0nMR4dvDtHiT+C0pqoSVClomevBvA1i9zsdwkPeAyVUjWvvFInhdvwOKiJlGFD0Rk5dDi2llkHn41/2ObY= X-Received: by 2002:a6b:3806:: with SMTP id f6mr1805827ioa.120.1567122316168; Thu, 29 Aug 2019 16:45:16 -0700 (PDT) MIME-Version: 1.0 References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> In-Reply-To: From: Ed Maste Date: Thu, 29 Aug 2019 19:44:59 -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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46KK3d4fxyz4Klf 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.54 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.49 / 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)[54.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.50)[ip: (-6.78), 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:45:18 -0000 >> 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 t= hrough 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? > Sometimes yes, sometimes no. Even with git svn, there is a cost associate= d with it. The level of effort is not zero. Especially when one pushes sev= eral 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 fric= tion 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.