Maybe it would also help to add more explicit instructions to the wiki ( https://bitbucket.org/petsc/petsc/wiki/Home#markdown-header-contributing-to-petsc) on how to construct a branch that is likely to get through the integration steps quickly.
I'd suggest adding language about these (and volunteer to write it), even if some might be obvious: - Adding tests for whatever you submit - Testing with configurations other than the usual double/real/C setup (complex, single) - Making the PR as small/atomic as possible (can your PR be 2 or more separate PRs?) - Running through valgrind (using --download-mpich) before submitting 2018-03-01 12:33 GMT+01:00 Karl Rupp <[email protected]>: > Dear PETSc folks, > > I think we can do a better job when it comes to handling pull requests > (PRs). We have several PRs piling up, which after some time (imho) get > merged relatively carelessly instead of reaping the full benefits of a > thorough review. > > In order to improve the integration of pull requests, I propose to > nominate a PR integrator, who is a-priori responsible for *all* incoming > PRs. The PR integrator is free to delegate a particular PR integration to > someone with the relevant domain-specific knowledge (e.g. Matt for > DMPlex-related things) by appropriate comments on Bitbucket. In case of > delays, the PR integrator is also responsible for issuing reminders over > time (like Barry has done in the past). > > The idea is to make daily progress with the PRs. One integration step per > day (e.g. testing or merging to next) is presumably enough to handle the > load, whereas things get messy if we let things pile up. Automated testing > may help a bit in the future, but it doesn't release us from properly > reviewing the contributed code. Any objections to my PR integrator proposal? Any volunteers? ;-) > If nobody else wants to be the highly esteemed PR integrator, I can do it. > ;-) > > Best regards, > Karli >
