Mailing List Archive

the future of commit bits
tl;dr: We are going to slightly simplify the permissions on the perl5.git repository. On top of that, we have a simple rule for who needs to agree that a merge commit should get merged.

What follows is broad strokes with some details yet to be refined, and I figure we'll refine them over time. But this is the plan, and you should let us know what needs work. I'll look at updating the pod in the near future.

Questions people sometimes ask:
* how do I get a commit bit?
* how do I get a PR approved?
* can I merge this PR that looks good to me?
The pod about the repo doesn't really answer these questions. The permissions on the repo are confusing to start, because there are a bunch of groups with very little explanation. Here is our plan:

Write access to the repo is either *Committer* or *Releaser* access. Both have write access to the repo. Releasers have access for the limited scope of making one or more releases and doing only the required work to do that. Committers have general-purpose write access, and use it to apply approved changes. Committers *also* do the approving.

When can a merge request be merged?
* If it's doc or test changes, one committer (other than the author) must approve the MR.
* If it's a bugfix or changes to features, two committers (other than the author) must approve the MR.
* When objections are raised, they should be discussed and addressed. "Addressed" doesn't mean "everybody agrees," but that the rationale for making the change in the face of the objection is clearly stated.
* Non-trivial MRs should wait to be merged for a minimum period of time so that discussion can occur. How long? It's proportional to the impact of the change. A few days is a good start. (A trivial MR is something like "fix a typo" or "rebuild perldoc".)
* Subject matter expert committers can issue a veto. If Karl says "this change to how we match Unicode properties will have serious negative impacts," he gets to block the merge at least until the situation is better understood.
* When things seem stuck, contact Neil, Rik, or Sawyer to get things unstuck.
Who is in what teams?
* Rik will be consolidating the too-many teams. Current "full committers" will not be losing access. Some releasers who don't do releases any more may. Let Rik know if you seem to lose access and don't think you should. It is probably a mistake.
* After that, people are added to or removed from the permission groups by the steering council, who are happy to receive suggestions for new additions.
* There may be some future removal of long-unused commit access, but nothing is planned right now.
I plan to start updating GitHub soon. No matter what, our current permissions kind of a mess.

Feedback on this is hereby solicited!

--
rjbs
Re: the future of commit bits [ In reply to ]
On Tue, Jan 12, 2021 at 01:57:31PM -0500, Ricardo Signes wrote:
> tl;dr: We are going to slightly simplify the permissions on the perl5.git repository. On top of that, we have a simple rule for who needs to agree that a merge commit should get merged.
>
> What follows is broad strokes with some details yet to be refined, and I figure we'll refine them over time. But this is the plan, and you should let us know what needs work. I'll look at updating the pod in the near future.
>
> Questions people sometimes ask:
> * how do I get a commit bit?
> * how do I get a PR approved?
> * can I merge this PR that looks good to me?
> The pod about the repo doesn't really answer these questions. The permissions on the repo are confusing to start, because there are a bunch of groups with very little explanation. Here is our plan:
>
> Write access to the repo is either *Committer* or *Releaser* access. Both have write access to the repo. Releasers have access for the limited scope of making one or more releases and doing only the required work to do that. Committers have general-purpose write access, and use it to apply approved changes. Committers *also* do the approving.
>
> When can a merge request be merged?
> * If it's doc or test changes, one committer (other than the author) must approve the MR.
> * If it's a bugfix or changes to features, two committers (other than the author) must approve the MR.

I like the idea, but I don't think we have enough active committers for it to work.

Are committers permitted to commit directly or are they required to
make a MR? (implied, but not explicitly mentioned)

Tony
Re: the future of commit bits [ In reply to ]
On Wed, 13 Jan 2021 09:42:21 +1100
Tony Cook <tony@develop-help.com> wrote:

> I like the idea, but I don't think we have enough active committers
> for it to work.

I'd be happy to do more code-review kinds of things - feel free to
involve me more in such things. :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: the future of commit bits [ In reply to ]
On Tue, Jan 12, 2021, at 5:42 PM, Tony Cook wrote:
> I like the idea, but I don't think we have enough active committers for it to work.

Putting aside what I or anybody else thinks: what do you think about the realism if we include the author in the count, if they are a committer?
* typo/trivial fix requires one committer, which may be the author
* larger change requires two committers, one of which may be the author?

> Are committers permitted to commit directly or are they required to make a MR? (implied, but not explicitly mentioned)

I don't know that we made it very explicit in our discussion, but I believe that a committer would not commit directly, but would instead make an MR. I realize this makes an impact on the pace of making small changes, and am interested in your feedback (and that of the rest of the crew).

--
rjbs
Re: the future of commit bits [ In reply to ]
On Tue, Jan 12, 2021 at 3:16 PM Ricardo Signes <rjbs@manxome.org> wrote:

> I don't know that we made it very explicit in our discussion, but I
> believe that a committer would not commit directly, but would instead make
> an MR. I realize this makes an impact on the pace of making small changes,
> and am interested in your feedback (and that of the rest of the crew).
>

Perhaps others might feel strongly the other way, but personally I would
not be inclined to create a pull request unless I intended to post the
changes for review/comment, and if the change is small enough (and in a
single commit) I wouldn't even make a separate branch for it, but just
commit directly on blead.
Re: the future of commit bits [ In reply to ]
On Tue, Jan 12, 2021 at 11:42 PM Tony Cook <tony@develop-help.com> wrote:
>
> On Tue, Jan 12, 2021 at 01:57:31PM -0500, Ricardo Signes wrote:
> > tl;dr: We are going to slightly simplify the permissions on the perl5.git repository. On top of that, we have a simple rule for who needs to agree that a merge commit should get merged.
> >
> > What follows is broad strokes with some details yet to be refined, and I figure we'll refine them over time. But this is the plan, and you should let us know what needs work. I'll look at updating the pod in the near future.
> >
> > Questions people sometimes ask:
> > * how do I get a commit bit?
> > * how do I get a PR approved?
> > * can I merge this PR that looks good to me?
> > The pod about the repo doesn't really answer these questions. The permissions on the repo are confusing to start, because there are a bunch of groups with very little explanation. Here is our plan:
> >
> > Write access to the repo is either *Committer* or *Releaser* access. Both have write access to the repo. Releasers have access for the limited scope of making one or more releases and doing only the required work to do that. Committers have general-purpose write access, and use it to apply approved changes. Committers *also* do the approving.
> >
> > When can a merge request be merged?
> > * If it's doc or test changes, one committer (other than the author) must approve the MR.
> > * If it's a bugfix or changes to features, two committers (other than the author) must approve the MR.
>
> I like the idea, but I don't think we have enough active committers for it to work.
>
> Are committers permitted to commit directly or are they required to
> make a MR? (implied, but not explicitly mentioned)

This is a concern. I don't think this will work without commitment
from the committers.

That said, I do think more reviewing than currently happens is a good
idea, I'm in.

Leon
Re: the future of commit bits [ In reply to ]
On Tue, 12 Jan 2021, 23:16 Ricardo Signes, <rjbs@manxome.org> wrote:

> On Tue, Jan 12, 2021, at 5:42 PM, Tony Cook wrote:
>
> I like the idea, but I don't think we have enough active committers for it
> to work.
>
>
> Putting aside what I or anybody else thinks: what do you think about the
> realism if we include the author in the count, if they are a committer?
>
> - typo/trivial fix requires one committer, which may be the author
> - larger change requires two committers, one of which may be the
> author?
>
> That sounds good to me. It stops short of creating a needless burden for
trivial changes, but stills introduces code reviews for larger changes.

That's exactly the system my $workplace has used for as long as I can
remember and has always worked well there.



> Are committers permitted to commit directly or are they required to make a
> MR? (implied, but not explicitly mentioned)
>
>
> I don't know that we made it very explicit in our discussion, but I
> believe that a committer would not commit directly, but would instead make
> an MR. I realize this makes an impact on the pace of making small changes,
> and am interested in your feedback (and that of the rest of the crew).
>

A committer would commit trivial changes directly with your revised plan
above, so sufficiently small changes would be unaffected.

It does require honesty and discipline on the part of the committers to not
abuse the system, but it's never been an issue at $work and I would
certainly trust people here to likewise exercise good judgement over
whether a change needs review or not.
Re: the future of commit bits [ In reply to ]
On Tue, Jan 12, 2021 at 06:08:21PM -0500, Ricardo Signes wrote:
> On Tue, Jan 12, 2021, at 5:42 PM, Tony Cook wrote:
> > I like the idea, but I don't think we have enough active committers for it to work.
>
> Putting aside what I or anybody else thinks: what do you think about the realism if we include the author in the count, if they are a committer?
> * typo/trivial fix requires one committer, which may be the author
> * larger change requires two committers, one of which may be the author?

I think it's more realistic.

> > Are committers permitted to commit directly or are they required to make a MR? (implied, but not explicitly mentioned)
>
> I don't know that we made it very explicit in our discussion, but I believe that a committer would not commit directly, but would instead make an MR. I realize this makes an impact on the pace of making small changes, and am interested in your feedback (and that of the rest of the crew).

I've tended to make a PR for non-trivial changes (a github PR now, a
patch attached to a ticket with RT, which led to other problems in RT
times)

I can see a need for direct commits in emergencies, specifically in
the case of a broken build. These are typically trivial commits though.

I can see it being a problem for small but non-trivial changes
(wherever you happen to draw those lines.)



Tony
Re: the future of commit bits [ In reply to ]
On 1/12/21 6:14 PM, Tony Cook wrote:
> On Tue, Jan 12, 2021 at 06:08:21PM -0500, Ricardo Signes wrote:
>> On Tue, Jan 12, 2021, at 5:42 PM, Tony Cook wrote:
>>> I like the idea, but I don't think we have enough active committers for it to work.
>>
>> Putting aside what I or anybody else thinks: what do you think about the realism if we include the author in the count, if they are a committer?
>> * typo/trivial fix requires one committer, which may be the author
>> * larger change requires two committers, one of which may be the author?
>
> I think it's more realistic.

I agree that this would be the ideal world solution, and the revision is
more realistic, but I doubt that it is still realistic enough.

A huge percentage of my commits these past few months have been
Warnocked. After a while I committed them anyway, and just merged the
ones I was confident about directly.

I have eventually committed other people's work that I did not
understand fully, when no one else did, because at that point in the
development cycle, it is important to keep things moving, and to
encourage people to continue on the project. I tried to get private buy
in from non-committers who have a good track record, in my opinion,
before doing so. But I was not always successful in getting them to
engage. A thumb's up on the PR encourages me. I haven't regretted any
of them. (I did look, and no trojan horses jumped out at me.)

Before I had a commit bit, an important commit of mine languished for 6
months because it was complicated and dealing in an area few if any
people still on the project knew much about. I could easily have packed
up my marbles and gone elsewhere, and I was tempted to. That commit led
to fixing many of the qr//i bugs with Unicode, which the project didn't
even know it had. It would have been better to merge it early in the
cycle even without understanding it, knowing there was time to fix the
bugs or revert it before ship date.

I don't know what the answer is. I do think project timing should be a
consideration.
>
>>> Are committers permitted to commit directly or are they required to make a MR? (implied, but not explicitly mentioned)
>>
>> I don't know that we made it very explicit in our discussion, but I believe that a committer would not commit directly, but would instead make an MR. I realize this makes an impact on the pace of making small changes, and am interested in your feedback (and that of the rest of the crew).
>
> I've tended to make a PR for non-trivial changes (a github PR now, a
> patch attached to a ticket with RT, which led to other problems in RT
> times)
>
> I can see a need for direct commits in emergencies, specifically in
> the case of a broken build. These are typically trivial commits though.
>
> I can see it being a problem for small but non-trivial changes
> (wherever you happen to draw those lines.)
>
>
>
> Tony
>
Re: the future of commit bits [ In reply to ]
On Tue, Jan 12, 2021 at 10:24 PM Karl Williamson
<public@khwilliamson.com> wrote:
>
> On 1/12/21 6:14 PM, Tony Cook wrote:
> > On Tue, Jan 12, 2021 at 06:08:21PM -0500, Ricardo Signes wrote:
> >> On Tue, Jan 12, 2021, at 5:42 PM, Tony Cook wrote:
> >>> I like the idea, but I don't think we have enough active committers for it to work.
> >>
> >> Putting aside what I or anybody else thinks: what do you think about the realism if we include the author in the count, if they are a committer?
> >> * typo/trivial fix requires one committer, which may be the author
> >> * larger change requires two committers, one of which may be the author?
> >
> > I think it's more realistic.
>
> I agree that this would be the ideal world solution, and the revision is
> more realistic, but I doubt that it is still realistic enough.
>
> A huge percentage of my commits these past few months have been
> Warnocked. After a while I committed them anyway, and just merged the
> ones I was confident about directly.
>
> I have eventually committed other people's work that I did not
> understand fully, when no one else did, because at that point in the
> development cycle, it is important to keep things moving, and to
> encourage people to continue on the project. I tried to get private buy
> in from non-committers who have a good track record, in my opinion,
> before doing so. But I was not always successful in getting them to
> engage. A thumb's up on the PR encourages me. I haven't regretted any
> of them. (I did look, and no trojan horses jumped out at me.)
>
> Before I had a commit bit, an important commit of mine languished for 6
> months because it was complicated and dealing in an area few if any
> people still on the project knew much about. I could easily have packed
> up my marbles and gone elsewhere, and I was tempted to. That commit led
> to fixing many of the qr//i bugs with Unicode, which the project didn't
> even know it had. It would have been better to merge it early in the
> cycle even without understanding it, knowing there was time to fix the
> bugs or revert it before ship date.
>
> I don't know what the answer is. I do think project timing should be a
> consideration.

I don't know either, but I agree that there is the potential for
throwing sand in the gears of getting work done. I know that code
review is considered "best practices" and it is certainly a nice thing
to have if you can afford it. I'm sceptical whether we can afford it.
I've always wished for more feedback on my work in various settings
(not just Perl) and seldom found people who had the time to provide
it. Traditionally commit bits have been handed out when folks got
tired of reviewing patches outside of their area of expertise and the
patch submitter had a generally good reputation for work that didn't
cause trouble.

People have mentioned following a similar process at $work. We have
recently started a similar process where I work and the code reviewers
are swamped. One of them recently told me he's lucky to get two hours
a day to do his own work. In a business setting this can theoretically
be managed by designating more resources, but I don't see that
happening in a volunteer setting.

There is also the opportunity cost of adding another step that is
particularly painful for occasional contributors like me. If I only
get a couple of hours every seventh Sunday to do Perl-related work,
waiting a few weeks for a code review would pretty much put that into
the why bother category.
Re: the future of commit bits [ In reply to ]
On Thu, 14 Jan 2021 at 04:43, Craig A. Berry <craig.a.berry@gmail.com> wrote:
>
> On Tue, Jan 12, 2021 at 10:24 PM Karl Williamson
> <public@khwilliamson.com> wrote:
> >
> > On 1/12/21 6:14 PM, Tony Cook wrote:
> > > On Tue, Jan 12, 2021 at 06:08:21PM -0500, Ricardo Signes wrote:
> > >> On Tue, Jan 12, 2021, at 5:42 PM, Tony Cook wrote:
> > >>> I like the idea, but I don't think we have enough active committers for it to work.
> > >>
> > >> Putting aside what I or anybody else thinks: what do you think about the realism if we include the author in the count, if they are a committer?
> > >> * typo/trivial fix requires one committer, which may be the author
> > >> * larger change requires two committers, one of which may be the author?
> > >
> > > I think it's more realistic.
> >
> > I agree that this would be the ideal world solution, and the revision is
> > more realistic, but I doubt that it is still realistic enough.
> >
> > A huge percentage of my commits these past few months have been
> > Warnocked. After a while I committed them anyway, and just merged the
> > ones I was confident about directly.
> >
> > I have eventually committed other people's work that I did not
> > understand fully, when no one else did, because at that point in the
> > development cycle, it is important to keep things moving, and to
> > encourage people to continue on the project. I tried to get private buy
> > in from non-committers who have a good track record, in my opinion,
> > before doing so. But I was not always successful in getting them to
> > engage. A thumb's up on the PR encourages me. I haven't regretted any
> > of them. (I did look, and no trojan horses jumped out at me.)
> >
> > Before I had a commit bit, an important commit of mine languished for 6
> > months because it was complicated and dealing in an area few if any
> > people still on the project knew much about. I could easily have packed
> > up my marbles and gone elsewhere, and I was tempted to. That commit led
> > to fixing many of the qr//i bugs with Unicode, which the project didn't
> > even know it had. It would have been better to merge it early in the
> > cycle even without understanding it, knowing there was time to fix the
> > bugs or revert it before ship date.
> >
> > I don't know what the answer is. I do think project timing should be a
> > consideration.

That's a good point. I'm sure we have committed risky-ish things
earlier in dev cycles at $work, sometimes even deliberately leaving a
commit until the next dev cycle starts before committing it, where
there is more of an unknown quantity in the change. Sometimes it just
isn't feasible to review and test changes to the usual standards for
various reasons (e.g. hoary old code that rarely gets touched, written
by people who have long since left).

>
> I don't know either, but I agree that there is the potential for
> throwing sand in the gears of getting work done. I know that code
> review is considered "best practices" and it is certainly a nice thing
> to have if you can afford it. I'm sceptical whether we can afford it.
> I've always wished for more feedback on my work in various settings
> (not just Perl) and seldom found people who had the time to provide
> it. Traditionally commit bits have been handed out when folks got
> tired of reviewing patches outside of their area of expertise and the
> patch submitter had a generally good reputation for work that didn't
> cause trouble.
>
> People have mentioned following a similar process at $work. We have
> recently started a similar process where I work and the code reviewers
> are swamped. One of them recently told me he's lucky to get two hours
> a day to do his own work. In a business setting this can theoretically
> be managed by designating more resources, but I don't see that
> happening in a volunteer setting.
>
> There is also the opportunity cost of adding another step that is
> particularly painful for occasional contributors like me. If I only
> get a couple of hours every seventh Sunday to do Perl-related work,
> waiting a few weeks for a code review would pretty much put that into
> the why bother category.

At $work it swings this way and that: Sometimes person A writes so
much code quickly that person B is swamped reviewing/testing it for a
week or more, but sooner or later person A will get stalled for a
while (either fixing problems found in review/testing, or working on
another task that isn't so easy) - and then person B gets on a roll
writing code.

I can see that being more of a problem here, though, because some
people (especially those being paid TPF grants, and maybe some others
in $workplaces that sanction them spending some time on perl) spend
many more hours on the project than other occasional contributors. The
occasional contributors surely won't want to spend much of their time
reviewing, but neither will the more active contributors want to have
to do all the reviewing.
Re: the future of commit bits [ In reply to ]
Thanks for the feedback! I think there are couple key things that got called out:
* a bunch of people want more review
* there is skepticism that saying its required will make it happen
* nobody wants to get stuck behind a wall of silence
Part of the impetus for this discussion was another point:
* nobody wants to get stuck when they get a volunteer reviewer who foot-drags or nit-picks
I also appreciated this comment from Craig:
> Traditionally commit bits have been handed out when folks got tired of reviewing patches outside of their area of expertise and the patch submitter had a generally good reputation for work that didn't cause trouble.

Altogether, maybe a structure like this is better:
* committers should commit their work after an appropriate review period spent as a pull request
* trivial or obviously-correct (!) changes may be committed directly (i.e., the appropriate length is sometimes zero)
* if objections are raised, they need to be addressed (meaning "clearly replied to")
* if the objection is from a subject matter expert, you need to come to an agreement
* if the above fails, ping neilb/rjbs/sawyer for adjudication, which I expect will be quite rare
I think this is very simple, very close to what we do now, and avoids "I was waiting a very long time" because one is free to say, "Well, I am applying this as I can't get feedback and believe it is correct.

The final things to mention are probably:
* for "I think this is right but want to give a chance for comments", a couple days is probably fine
* for "this is a significant change that I could really use feedback on," a week or more is probably best, and the PR should probably be flagged to the list as wanting attention
* the later in the release cycle, the stricter we should be with ourselves
* don't panic; changes can be reverted
Is this good?

--
rjbs
Re: the future of commit bits [ In reply to ]
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
:The final things to mention are probably:
: * for "I think this is right but want to give a chance for comments", a couple days is probably fine
: * for "this is a significant change that I could really use feedback on," a week or more is probably best, and the PR should probably be flagged to the list as wanting attention
: * the later in the release cycle, the stricter we should be with ourselves
: * don't panic; changes can be reverted
:Is this good?

Those timescales seem very short to me.

However my attitude is based on my $work experience dealing with high-risk
areas (notably in the handling of 10s or 100s of millions of credit-card
details). I suspect most people's experience has involved programs in which
the potential fallout from errors is much lower impact.

It is not clear to me where errors in perl itself fall on that spectrum:
those using it for high-risk work will likely be taking responsibility
themselves for qualifying any new release of perl for their own application.

But maybe it would be useful if the steering committee could develop and
communicate a clear vision of what degree of risk they're happy to take on
in shipping code that has had lesser review - effectively, which users they
see as a target audience that should be expected to _trust_ a new release.

Hugo
Re: the future of commit bits [ In reply to ]
On Sat, Jan 16, 2021, at 1:22 PM, hv@crypt.org wrote:
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
> :The final things to mention are probably:
> : * for "I think this is right but want to give a chance for comments", a couple days is probably fine
> : * for "this is a significant change that I could really use feedback on," a week or more is probably best, and the PR should probably be flagged to the list as wanting attention
> : * the later in the release cycle, the stricter we should be with ourselves
> : * don't panic; changes can be reverted
> :Is this good?
>
> Those timescales seem very short to me.

Briefly reply now because I'm worried I'll forget later:

I agree, they feel short to me, but I know that's because I'm considering them in the context of paid work. In paid work, one's colleagues have (say) forty hour-long timeslices in a week, and allocating a few for you is not an enormous cost. In work on the Perl core, very few of us have that many timeslices available for Perl work, and using it on review will feel, for most people, like second-order work that helps some other volunteer achieve their goals, rather than one's own goals.

This means, perforce, that we need to limit the things that can be blocked by non-review. As you say, it's a question of risk. I want to acknowledge that commit bits have been given to people who we believe are good at policing their own risk.

(Also, having a lot more active, expert committers would allow stricter requirements, but we're not there at the moment.)

--
rjbs
Re: the future of commit bits [ In reply to ]
I think one big issue with code review is shallow versus deep review.

It's fairly easy to look over a commit and criticise a poor commit
message, point out that there aren't any tests included, spot typos, etc.

What's really hard for a non-trivial PR is being able to say with
confidence whether that change is (a) correct and (b) best.

Really the only way to be able to perform a good deep review is for a
reviewer to independently attempt to fix the same issue. This forces them
to understand how the existing code works, and what might be good ways to
fix it.

So for example Karl might post some big Unicode fix, and for me to be able
to review it properly might take me as much if not more time than Karl
took.

I don't think we have the resources to do deep reviews.

I think shallow reviews of committer changes already get done by people
who have a habit of regularly running an eye over recent commits to
understand what's going on.

Shallow reviews of non-committer PRs should of course be carried out. And
if they're in a specialised area (e.g. regexes) then there would be an
expectation that an expert in that area would carry out a review somewhere
in between shallow and deep.

So what I think I'm saying is that there isn't much point in requiring
approval from another committer for a PR/commit by a committer, and I'm
not sure there's need for 2 reviewers for a non-committer PR.

--
You're only as old as you look.
Re: the future of commit bits [ In reply to ]
> I don't think we have the resources to do deep reviews.

I agree with this.



2021?1?18?(?) 21:21 Dave Mitchell <davem@iabyn.com>:

> I think one big issue with code review is shallow versus deep review.
>
> It's fairly easy to look over a commit and criticise a poor commit
> message, point out that there aren't any tests included, spot typos, etc.
>
> What's really hard for a non-trivial PR is being able to say with
> confidence whether that change is (a) correct and (b) best.
>
> Really the only way to be able to perform a good deep review is for a
> reviewer to independently attempt to fix the same issue. This forces them
> to understand how the existing code works, and what might be good ways to
> fix it.
>
> So for example Karl might post some big Unicode fix, and for me to be able
> to review it properly might take me as much if not more time than Karl
> took.
>
> I don't think we have the resources to do deep reviews.
>
> I think shallow reviews of committer changes already get done by people
> who have a habit of regularly running an eye over recent commits to
> understand what's going on.
>
> Shallow reviews of non-committer PRs should of course be carried out. And
> if they're in a specialised area (e.g. regexes) then there would be an
> expectation that an expert in that area would carry out a review somewhere
> in between shallow and deep.
>
> So what I think I'm saying is that there isn't much point in requiring
> approval from another committer for a PR/commit by a committer, and I'm
> not sure there's need for 2 reviewers for a non-committer PR.
>
> --
> You're only as old as you look.
>