Hi Richard,

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).

Best regards,

Reply via email to