[petsc-dev] Our pull request work flow is terrible and horrible

[Patrick Sanan]

2018-01-12 15:24 GMT-08:00 Smith, Barry F. <bsmith at mcs.anl.gov>:

>
>
> > On Jan 12, 2018, at 4:32 PM, Patrick Sanan <patrick.sanan at gmail.com>
> wrote:
> >
> >
> >
> > 2018-01-11 22:36 GMT-08:00 Smith, Barry F. <bsmith at mcs.anl.gov>:
> >
> >
> > > On Jan 11, 2018, at 11:40 AM, Patrick Sanan <patrick.sanan at gmail.com>
> wrote:
> > >
> > > One idea is to impose a stricter guideline that things on the
> bitbucket PR page are things that everyone is actively trying to merge.
> That way, maintainers can just look at the bottom of the list to see what's
> lagging, instead of having to to work up the list and try to remember which
> of the PRs are WIP or proposals or experiments or even abandoned ideas.
> >
> >   Very valid point. Perhaps we could have some way to convert the
> "proposals" to Issues so they are not lost but no longer clog the pull
> requests. Or the originator of the pull request (i.e. Jed) could kindly
> remove the pull request by converting it to some other archival form. Or at
> least label the pull request as Archival as opposed to active.
> >
> > Any reason to not just create/select an issue, assign it to someone, and
> include the relevant branch name in the issue description?
>
>    Hmm, now there are two things to keep track of for each pull request
> (the pull request web page and the issue web page) so you've doubled the
> pain just so you can use the bitbucket issue assigner to know who is
> assigned to it.
>
I meant to suggest to do this only for "not actively trying to merge" PRs
that you want to take off the PR page and convert to issues.

>
>     Put you have a very valid point. We do need to assign each pull
> request to someone. We could simply leave at the first comment on the pull
> request the assigned. For example @barrysmith you are assigned this pull
> request. Then that person turns on watching for the request.
>
I think this was actually Matt's point, but seems reasonable to me as well
: )

>
>   Barry
>
> >   Barry
> >
> > >
> > > This probably requires an itchier trigger finger on declining PRs
> which need substantial work.
> > >
> > > A related point is that (as happened with the last PR I made), if a
> big edit is performed after the original PR is made or even approved, then
> it's not always clear "whose court" the PR is in. Maybe it's better to just
> make a new PR in this situation. I'm not sure if bitbucket allows you to
> decline your own PR (I fear not) - that would make this easier.
> > >
> > > 2018-01-11 9:00 GMT-08:00 Smith, Barry F. <bsmith at mcs.anl.gov>:
> > >
> > >    what do people suggest to improve it.
> > >
> > >     We can't have valuable pieces of code going stale in there for
> months.
> > >
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180112/b9a257e6/attachment.html>