Date: Wed, 20 Jun 2018 16:28:46 -0230 From: "Jonathan Anderson" <jonathan@FreeBSD.org> To: "Jonathan T. Looney" <jtl@freebsd.org> Cc: hackagadget@gmail.com, "Conrad Meyer" <cem@freebsd.org>, "Ian Lepore" <ian@freebsd.org>, "Simon J. Gerraty" <sjg@juniper.net>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl Message-ID: <FAE743DA-A68B-4B52-A642-8B32AED79DE6@FreeBSD.org> In-Reply-To: <CADrOrmu=cQBNqU2_onT_s=pPhB0A546Nf9Sy5RcZzL0%2BAurpDQ@mail.gmail.com> References: <201806200108.w5K18sIR050132@repo.freebsd.org> <CAG6CVpV124ze%2BY6xX2ZFqbM%2B3hJNEJWR2qpnChpey=PmiW6qXg@mail.gmail.com> <96021.1529475664@kaos.jnpr.net> <CAJ5_RoBvwNH7-ZCd3LxtXg21TE49uX2y35Jwa6MM%2Bwn%2BX0_wUQ@mail.gmail.com> <17033.1529508519@kaos.jnpr.net> <CAG6CVpVwrWaDMcVRfgaOHagfPbnmULKe6R=GJiZi-reZYbZr8A@mail.gmail.com> <1529510299.24573.5.camel@freebsd.org> <CAG6CVpUgy8LhCkFZZ1D8BH%2BqJ_CDikvYNJrM9Nc0Ut5u=AVMHA@mail.gmail.com> <CAEm%2B2uVXQc7%2Bx6tmQyfeiU4rYKFMCcFZ2Q3_SHA1jf%2BOoHThfg@mail.gmail.com> <CADrOrmu=cQBNqU2_onT_s=pPhB0A546Nf9Sy5RcZzL0%2BAurpDQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
> On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan
> <hackagadget@gmail.com>
> wrote:
>> And I was working on those sets of changes, when work and family
>> didn't
>> steal away time. I was told that some discussion happened at BSDCan
>> this
>> year in such that veriexec should go in as-is so it would be there,
>> which
> is why
>> the commit happened (given the review was approved to land back in
> January.)
>
> I will readily admit that I was probably the source of this. 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").
>
> ([...] I wasn't intending to push Steve to commit
> this before he was ready.)
I suspect I was part of that push, and while it's provoked some
discussion I still think it was the right course of action. Simon and I
chatted about these changes at BSDCan (starting with my apologies for
not doing the asked-for review two years ago!) and I suggested that,
since the changes had been accepted in Phabricator in January and nobody
had raised any objections since then (see: D85{61,62,75}), it would
probably be better to commit and iterate than to continue waiting for an
unspecified number of additional reviews that might never come. Now that
the code has landed it's sparked some lively discussion about potential
improvements, but that's a much better situation than the silence Steve
heard for a long time in Phabricator.
So: is there a strong reason why a backout-and-re-commit approach is
superior to iterating on the code in-tree? SHA-1 doesn't give me the
warm fuzzies either, but I don't see why the whole framework has to be
backed out rather than just receive incremental improvements, e.g.,
disabling or removing SHA-1 while keeping it easy for downstream
consumers to re-enable/re-add whatever algorithms their customers want.
Jon
--
jonathan@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAE743DA-A68B-4B52-A642-8B32AED79DE6>