Manual backports with compatibility patches

[BridgeAR]

Regular manual backports are currently done by changing the actual code change and applying the necessary changes directly to the backported commit.

I would like to change that to always use the original commit without any changes and to add another commit afterwards that works as compatibility patch. That way it's

a) easier to review the changes and accept the PR faster
b) potential conflicts will normally happen with the compatibility patches instead of the original commit.

Especially the second point could reduce the amount of work necessary in case of conflicts (it would be easier to determine what's wrong).

I can think of one downside though: in theory bisecting could become more difficult because the original commit could cause problems. It should likely mostly not be an issue besides broken builds.

[MylesBorins]

How would this work when there is a conflict? More often then not the changes to a commit are duebto conflicts not compatibility. This would 100% break bisecting though. I do not think the benefit outweighs breaking bisecting

…

On Tue, Aug 6, 2019, 7:34 AM Ruben Bridgewater ***@***.***> wrote: Regular manual backports are currently done by changing the actual code change and applying the necessary changes directly to the backported commit. I would like to change that to always use the original commit without any changes and to add another commit afterwards that works as compatibility patch. That way it's a) easier to review the changes and accept the PR faster b) potential conflicts will normally happen with the compatibility patches instead of the original commit. Especially the second point could reduce the amount of work necessary in case of conflicts (it would be easier to determine what's wrong). I can think of one downside though: in theory bisecting could become more difficult because the original commit could cause problems. It should likely mostly not be an issue besides broken builds. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#468?email_source=notifications&email_token=AADZYVZBVWT64IAJRANVRHTQDFOVDA5CNFSM4IJVMIK2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDTOGIQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADZYV7SBMRVKDTS35VUYULQDFOVDANCNFSM4IJVMIKQ> .

[BridgeAR]

Example:

Backport includes the changes in the same commit: nodejs/node#29013
Backport with separate compatibility patch: nodejs/node#29011

[targos]

I'm -1 on landing commits with conflict markers.
What we can maybe ask people to do is open the PR in two commits and squash them while landing.

[BridgeAR]

@targos

What we can maybe ask people to do is open the PR in two commits and squash them while landing.

I think that is a good middle ground. That way it's already easier to review.

@MylesBorins

How would this work when there is a conflict?

It would depend on how the conflict came up and it's somewhat difficult to predict that. I think recommending to open a PR with the changes as separate commit and to squash those while landing is already improvement enough that we can focus on that instead of my original proposal.

[BethGriggs]

Closing, as this is fairly old now and I don't believe we're pursuing this idea further. Please reopen if you feel closing is/was inappropriate here.