From owner-svn-src-head@freebsd.org Wed Jun 20 20:07:36 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE5AF10095CA; Wed, 20 Jun 2018 20:07:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81C6672814; Wed, 20 Jun 2018 20:07:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f53.google.com with SMTP id l6-v6so1460136iti.2; Wed, 20 Jun 2018 13:07:35 -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:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=3nhREAJuObgi78gtOmN7HUr+KbLA39/fuB25kdoYtKw=; b=tFw15PWgpjBH02AZN6nwg5ZI9bB1NoGrIbpluPpi49tW337vhJ+MFQcrlUh00sLsyo M43dprErMhL/DSuxgLJDzjZa/hfno3t4zcdsXDQWfaJpMShf+mqQvMM6haSjzWHlpMdg O8AJE+Z+1tidEpGwKSHD4eiYwigIeJMUenK5BRbIvf9ArOEwIszQGk6fWrLTVO1tQh1w YOrpehwHDZr1qMAcb6SFs0WWf5Uos7BNbRGkgMFcVh/UCvAyM4d8kiAjhBIdVxSeD221 fp2GtXyWpTqB9Rvm3wNfMJR9VpFiMfJpLWY6iBHSasjhaxyZ899wB6HZJpFm+AVUg4dT LSUg== X-Gm-Message-State: APt69E3v3tVmxIFzc/nb2lqEjVpEDnzsKpVie+JCUBx3fE/3xhtS2O+g c5TWnS37JApSXwalUxcQSgOlNaJS X-Google-Smtp-Source: ADUXVKLDh3ieF8MYRp53RWAFKrJBIoaajZ6lh6w0nur7MC26JFbcfsZmoyKNEE3Pjxhp+K4ri8zoAQ== X-Received: by 2002:a02:62ce:: with SMTP id d197-v6mr18485361jac.36.1529525249503; Wed, 20 Jun 2018 13:07:29 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id h81-v6sm197598ith.2.2018.06.20.13.07.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 13:07:29 -0700 (PDT) Received: by mail-io0-f177.google.com with SMTP id f1-v6so887439ioh.6; Wed, 20 Jun 2018 13:07:29 -0700 (PDT) X-Received: by 2002:a6b:da0e:: with SMTP id x14-v6mr18078270iob.19.1529525249058; Wed, 20 Jun 2018 13:07:29 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:5995:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 13:07:28 -0700 (PDT) In-Reply-To: References: <201806200108.w5K18sIR050132@repo.freebsd.org> <96021.1529475664@kaos.jnpr.net> <17033.1529508519@kaos.jnpr.net> <1529510299.24573.5.camel@freebsd.org> From: Conrad Meyer Date: Wed, 20 Jun 2018 13:07:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r335402 - head/sbin/veriexecctl To: Jonathan Anderson Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 20:07:36 -0000 Hi Jon, On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson wrote: > On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote: >> My reasoning >> was fairly simple: when a review has been open for over a year with no >> action, it seems like the submitter should be able to commit it without >> waiting for more review, if they are confident in their change. I stand by >> that (and, in fact, would substitute something shorter for "over a year"). For this as a question of general process, I think "it depends." For minor fixes? Of course! Less than one year. For minor improvements or enhancements? Also yes, also probably less than 1yr. For large features like this, I think the answer is more nuanced. Sometimes being in a review for a year means the reviewers are overloaded and don't have time. In that case, maybe they shouldn't block progress. Sometimes being in review for a year just means the right reviewers haven't been found. I think that was more the case here. I would suggest anyone submitting a large feature and not getting feedback in a reasonable timeframe to solicit feedback from a wider audience much sooner than one year, and also indicate intention to merge the unreviewed change with some time window (1-2 weeks?) on giving feedback or at least asking for more time to review. > So: is there a strong reason why a backout-and-re-commit approach is > superior to iterating on the code in-tree? Yeah: > Any disputed change must be backed out pending resolution of the dispute > if requested by a maintainer. Security related changes may override a > maintainer's wishes at the Security Officer's discretion. > > This may be hard to swallow in times of conflict (when each side is > convinced that they are in the right, of course) but a version control > system makes it unnecessary to have an ongoing dispute raging when it is > far easier to simply reverse the disputed change, get everyone calmed > down again and then try to figure out what is the best way to proceed. > If the change turns out to be the best thing after all, it can be easily > brought back. If it turns out not to be, then the users did not have to > live with the bogus change in the tree while everyone was busily > debating its merits. People very rarely call for back-outs in the > repository since discussion generally exposes bad or controversial > changes before the commit even happens, but on such rare occasions the > back-out should be done without argument so that we can get immediately > on to the topic of figuring out whether it was bogus or not. In particular, SHA1 was never the primary reason the backout was requested, just one design smell in the aggregate. This change introduces a security feature that doesn't provide the security guarantees it claims to. That should be a major red flag. All the best, Conrad