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

[Patrick Sanan]

Added.

2018-03-01 19:05 GMT+01:00 Stefano Zampini <stefano.zampini at gmail.com>:

> I would also add --with-clanguage=C++
>
>
>
> 2018-03-01 19:03 GMT+03:00 Smith, Barry F. <bsmith at mcs.anl.gov>:
>
>>
>>
>> > On Mar 1, 2018, at 8:36 AM, Patrick Sanan <patrick.sanan at gmail.com>
>> 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 <patrick.sanan at gmail.com>:
>> > 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 <vaclav.hapla at erdw.ethz.ch>:
>> >
>> >
>> >> 1. 3. 2018 v 14:04, Patrick Sanan <patrick.sanan at gmail.com>:
>> >>
>> >> 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 <rupp at iue.tuwien.ac.at>:
>> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180301/75130ae3/attachment.html>