From owner-freebsd-fcp@freebsd.org Fri Aug 30 00:19:16 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 8AAC7E45C6 for ; Fri, 30 Aug 2019 00:19:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46KKpr2RJWz4Qd5 for ; Fri, 30 Aug 2019 00:19:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 51553E45C5; Fri, 30 Aug 2019 00:19:16 +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 510F6E45C4 for ; Fri, 30 Aug 2019 00:19:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 46KKpq2nLWz4Qd2 for ; Fri, 30 Aug 2019 00:19:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id i78so3215075qke.11 for ; Thu, 29 Aug 2019 17:19:15 -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=j+SRZ5kUCBdK4V6FTFHS6+HnVnHlwC8XmWCMrEVfwHI=; b=OWeFDN3bJkNaDnRPUwTvNCeugNyhD4xZ34GEAduGSdcAywKWcb7gIbmJcHopvj9qt6 W99K1qGIV7nmZirLgfqeUx0lPHmDAUVKMU6XdJy7/QShvY4+UBzM+kb4FhmOegIm7f86 YJwwpgxNmRGQFhPhrnHyB909IMqi3BolNl2TaLLhj9HC/jCzOw/pN2DKVNOkrUiVh2mJ 90/QDLeTJKN2vXdidemzUg6fjyzrj9G/DZN860AeAMNooPxPmbHdyghjf62qhfNcMupe CTnl+dlI6H6sOfE7OWf75PuJLzvf9f665Od+20nkrtwXTv1W0k5sOQFUCwcQC7G3h3rs 0MMQ== 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=j+SRZ5kUCBdK4V6FTFHS6+HnVnHlwC8XmWCMrEVfwHI=; b=Al2If/0TrCPoX6wYoKZwvfyjOHPCBFpfLQkZLDNqIQ52iChTQc+y2CnUN9C85wf3JN zqj8YiJojb77m+n+nifil2JpwczSDL0xeDl1qSJamDz7gLIh78lo9R6BkWtcl09nsIld Orys7f5GStHrxr0hUk6d5XF5w/t9BcjDUPkWTupclHaafInNFdbNpp+bblVkH24MdCOV rkRzwlAv0mBg+mSKZFMW9zADGSbBDT1RcwK1uy5ip+obYn9yw59Fu088wFJyZoTsRoAq CHFR75xqdSZ63MYlUVUis+o6I5qxhYC8Fcg4jGQV6Wwe9vKCi/1FGPltkcAHPba6larj jGpQ== X-Gm-Message-State: APjAAAVrtZIQ6ICy4gwDKceee+HUa2XIvKa5HchbaC2r0xNSVAgSxSOy UmRShLat1dHmRfTGcPyJfQ+iabrpc0kYpICB5/u+vQ== X-Google-Smtp-Source: APXvYqyp1HtSIHpIEncgQbk5/qWyYzY5hebGyJRUdq3pgDtVRBbNWjTHqbXWgSN1y2Nh0mhffhqtpWVAY+ot7BFBNn4= X-Received: by 2002:a37:8902:: with SMTP id l2mr12348810qkd.380.1567124354153; Thu, 29 Aug 2019 17:19:14 -0700 (PDT) MIME-Version: 1.0 References: <201908291905.x7TJ5Bw8091371@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Thu, 29 Aug 2019 18:19:02 -0600 Message-ID: Subject: Re: FCP 20190401-ci_policy: CI policy To: Ed Maste Cc: FreeBSD Hackers , fcp@freebsd.org X-Rspamd-Queue-Id: 46KKpq2nLWz4Qd2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=OWeFDN3b; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.91 / 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)[e.2.7.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.91)[ip: (-9.34), 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: Fri, 30 Aug 2019 00:19:16 -0000 On Thu, Aug 29, 2019 at 5:45 PM Ed Maste wrote: > >> 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. > > 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? > I've twice lost work due to a hasty reversion in the past. In my case, when I did the svn update it ended badly due to the conflicts that were generated. Most of the times I've hit conflicts in the past, it's just been the work of a conflict. When the work was larger, svn got a bit confused and I wound up losing several chunks of work. I was able to redo it, but it was annoying. It's why a super-fast automatic revert without contact with the person that committed it is a bad idea. Of course, if that person falls down in fixing it, I support doing something. Tools have improved, and perhaps this is a case of once bitten twice shy... > > 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. > > 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. > I agree. My pushback here is against the notion there's zero cost to a revert. Of course we need balance the damage to others vs the impact on the contributor. When the impact is in -current on a fringe platform, we need to not over-react to fixing that by back out. > > 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... > > 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. > Agreed. I just don't want to swing too far to the automatic end of things, and to apply some level of judgement when there's more than one change involved. Warner