On 20 Jun 2018, at 15:32, Jonathan T. Looney wrote:
On Wed, Jun 20, 2018 at 9:49 AM Stephen Kiernan
<hackagad...@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
--
jonat...@freebsd.org
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
