Don't backport PR's before original changes are in?

Development
#1

In the last year or so I’ve been noticing that a lot of backport PR’s are opened before the original change has landed in one of the development branches (master/staging/staging-next). It’s good to see the initiative to backport, however, it is also problematic, because its

  1. not uncommon that the change on the development branch needs to be changed first
  2. the original change may be rebased instead of merged as is, causing the “cherry picked from …” hash to be incorrect.

It’s worth mentioning here that I often rebase PR’s instead of merge them as is, especially is they consist of just a single commit, just to get rid of the “Merge …” noise.

In my opinion we should not open any backport PR’s that include cherry-picked commits until the original change is in for the above mentioned reasons. What do you say?

5 Likes
#2

I think I’d be opposed to such a policy. You also have to consider the effort that has to go into backporting. When I create the PR, I’m already in “PR creating mode”. I have a terminal open in the right repository, I’m on the right branch. I track the remote branch, open the link github gives as a response to open a PR. Doing the backport then is just a matter of maybe ~3 additional commands.

Once the PR is merged, it would take more effort to make the backport. Not a lot more, but a little. At the same time the problem is less fresh on my mind, I may have already mentally put a checkmark next to it.

I do think such a small difference in convenience has a big impact on how many changes are actually backported. Ideally we’d have a bot for that, but as long as we don’t we should not increase the hurdle.

1 Like
#3

I think we should also consider the burden to reviewers. If you backport a change before review is complete, you may end up duplicating the review effort in the backport PR. As it currently stands, nixpkgs looks pretty review-bottlenecked.