[petsc-dev] Handling pull requests in a better way

[Karl Rupp]

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,
Karli