Added. 2018-03-01 19:05 GMT+01:00 Stefano Zampini <[email protected]>:
> I would also add --with-clanguage=C++ > > > > 2018-03-01 19:03 GMT+03:00 Smith, Barry F. <[email protected]>: > >> >> >> > On Mar 1, 2018, at 8:36 AM, Patrick Sanan <[email protected]> >> wrote: >> > >> > Proposed addition to https://bitbucket.org/petsc/pe >> tsc/wiki/Home#markdown-header-contributing-to-petsc : >> > >> > """ >> > Suggestions for a smooth review of your contributed code: >> > >> > - If adding features, include tests which cover them. >> > - Test your changes by running with valgrind (use `--download-mpich` to >> obtain a valgrind-clean MPI implementation). >> > - Test your changes with non-standard configurations of PETSc (in >> particular, `--with-precision=single` and `--with-scalar-type=complex`). >> >> Also add -with-64bit-indices >> >> > - If your contribution can be logically decomposed into 2 or more >> separate contributions, submit them in sequence instead of all at once. >> >> >> Looks good, go ahead and add these. >> >> > """ >> > >> > 2018-03-01 15:10 GMT+01:00 Patrick Sanan <[email protected]>: >> > A simple way to proceed would be to advise submitters to submit their >> "atomic" PRs in a valid order. If change B depends on change A, then submit >> A first, wait until merged, and then submit B. This would have the nice >> side effect of not overwhelming the integrators. >> > >> > 2018-03-01 15:04 GMT+01:00 Vaclav Hapla <[email protected]>: >> > >> > >> >> 1. 3. 2018 v 14:04, Patrick Sanan <[email protected]>: >> >> >> >> 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?) >> > >> > Yes, I think it's quite common that one would like to factor out one or >> more smaller bugfixes and/or improvements from a bigger PR. But some of >> them may depend on some others, and definitely the original big PR depends >> on all of them. Perhaps it would be nice if there is some documented way of >> specifying dependendencies between PRs to insure a proper order of merging >> (I think BitBucket has no such feature?). >> > >> > Thanks, >> > Vaclav >> > >> >> - 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 >> >> >> > >> > >> > >> >> > > > -- > Stefano >
