I'm a bit late to the discussion, but I want to point out one of the
issues I've encountered with pull requests: Often a pull request is
submitted with multiple reviewers listed, and it's sometimes not clear
how many of the reviewers need to look at it. I've spent some time
looking over pull requests that I'm a reviewer for, and then when things
look satisfactory, I mark it "approved". But sometimes my expertise only
pertains to a portion of the pull request, and at least one of the other
reviewers needs to look at it. Maybe those reviewers, in turn, figure
they don't need to look because I've already approved it. And sometimes
a pull request lists multiple reviewers, simply because any single one
of several people could probably review the request and then merge it.
In short: I think that one problem we have with pull requests is that
it's not exactly clear how many people need to bless a particular
request before approving and merging to next. On any request where Barry
is also listed as a reviewer, even if I've thoroughly reviewed something
and approved, I feel most comfortable waiting for Barry's blessing
before any "integration" happens. But this is not scalable in Barrys.
What is a better system?
well, we have several subsystems in PETSc that are best understood by
devs other than Barry, so I'm not too worried about the scalability.
The shared responsibility of PR integration was (imho) the major problem
of handling PRs in the past, much like a chore. By explicitly assigning
integration responsibility to one (who may decide to delegate it), there
should be no more implicit (and possibly circular) waiting for others to
take final action (as you described above).