#2859 RFE: pull request correction workflow
Opened by mikem. Modified

I'm not sure what the best answer here is. I'm open to different solutions, or even "you're doing it wrong, Mike." At any rate, I find this common pattern with PRs:

  1. PR is filed
  2. on review, I find that PR needs adjustment
  3. I checkout the PR, add some changes, push them $somewhere, and drop the link in the PR
  4. requester (hopefully) incorporates my changes
  5. rinse, repeat?... merge

The sticking points here around no. 3/4. Fetching from $somewhere is pretty manual and might not be the most convenient for requesters.

So... github has a feature where PRs can "Allow edits from maintainers." This is sort of rolls step 3&4 into one when the option is on. If Pagure could do this, it would certainly make this workflow a little cleaner.

That said, I don't want to demand a particular solution here. Maybe there are other (better?) ways to streamline this sort of back-and-forth commit workflow.


I know you're not the only person with this request and pagure does not currently have a satisfying answer to this question.

I'm not entirely sure how to implement this for the time being, but I'll try to give it some more thoughts.

Metadata Update from @pingou:
- Issue tagged with: RFE, discussion

So one thing that pagure 4.0 added is the possibility to change the target project of a PR. So you can fork the main project koji and from your fork you can open PR against the parent project (the main project) or any of the existing forks.

So for this workflow, you could open a PR against the fork of the contributor submitting a PR, against the branch used in the PR. If the contributor merges your PR into that branch, their PR will get automatically updated against the main project.

Does that help?

Hmm, I'll have to try that and see how it works.

So for this workflow, you could open a PR against the fork of the contributor submitting a PR, against the branch used in the PR. If the contributor merges your PR into that branch, their PR will get automatically updated against the main project.

Just tried to do this and only 11 of the 100 or so forks show up. It seems that the vast majority of forks have PRs disabled, which significantly reduces the odds of this workflow being useful.

I wonder, since we are now allowing rebases if we could also allow edits in a similar way. I expect it would be much more straightforward than the "reverse PR" appoach suggested, mainly because it removes the step of the requester having to merge the reverse PR.

It would be quite useful to allow that. It's a handy feature in GitLab and GitHub to allow maintainers to "clean up" before merging a pull request.

Metadata Update from @wombelix:
- Issue set to the milestone: 6.0

Metadata