svn commit: r335402 - head/sbin/veriexecctl

Stephen Kiernan hackagadget at
Wed Jun 20 21:28:18 UTC 2018

(Apologies to cem@ for the duplicate in his inbox, Gmail decided to not
reply-all in my reply.)

On Wed, Jun 20, 2018 at 1:07 PM, Conrad Meyer <cem at> wrote:

> Hi Jon,
> On Wed, Jun 20, 2018 at 11:58 AM, Jonathan Anderson
> <jonathan at> 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.

That was the problem. I soliticted feedback many times over at least 3
The first set was in my GitHub branch and I had discussed with various
people starting at BSDCan 3 or 4 years ago.

I had even sent an early version of the changes to rwatson (whom I had
previously worked with at TIS/NAI/McAfee) and was provided some
feedback based on a cursory look over of the code, which was integrated
into the branch.

At MeetBSD 2016, I also discussed the code with some people and that
was when it was suggested that I create an account of Phabricator and
put the code up for review. Some members of core and/or the Foundation
had suggested who to talk to get reviews and I had also spoken with
rwatson again to see if he had any suggestions.

Once the code had landed in review, I also talked with people during
vBSDcon last year in an effort to try to find out who else should put eyes
on it. I even talked about it during one of the BoF sessions and pointed
out both my GitHub branch and the set of reviews on Phabricator, which
is when there started to get some additional feedback and/or watchers
on the review.

Also, after I had received my commit bit and the reviews were still
dust in Phabricator, on numberous occassions I solicited feedback or
suggestions on who to contact on the IRC channel.

I'm guessing that people had not looked at the reviews before suggesting
who to talk to or they did not realize the areas of interest that the
might cover.

I think this experience illustrates the need for some better way for someone
contributing to be able to find out who the correct parties are that need
to be

It was 3+ year struggle for me to find people to put eyes on the code and it
was not just a fire it off and wait forever thing. One can only listen to
in response for requests for help for so long.


More information about the svn-src-head mailing list