[External] : Backporting a set of patches in a single commit
christoph.langer at sap.com
Thu Jul 22 21:37:48 UTC 2021
well, I think then we should try the dependent pull request feature on jdk11u-dev. Is there any drawback besides the additional branches created? Also, is there any documentation?
From: Kevin Rushforth <kevin.rushforth at oracle.com>
Sent: Mittwoch, 21. Juli 2021 23:37
To: Langer, Christoph <christoph.langer at sap.com>; skara-dev at openjdk.java.net; erik.joelsson at oracle.com
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: [External] : Backporting a set of patches in a single commit
Yes, I think one solution would be to enable the dependent pull request feature of Skara for your repo. It's already being used by the jdk project. Since it is already implemented and tested (at least for original fixes, but I can't think of anything that would preclude it for backports), it would be easy to set up so you could try it and see if it met your needs.
FWIW, I ran into this in a couple cases myself when backporting fixes to jfx11u after the Skara switch. I ended up testing them in a branch where I pulled in the relevant fixes I needed, and then did them as separate PRs in the right order. Since they were clean it took only a few extra minutes. It was the testing that took all the time anyway, but I couldn't help thinking that dependent pull requests would have made it easier.
On 7/21/2021 2:20 PM, Langer, Christoph wrote:
Hi Skara Team,
after gathering the first significant experiences with the backport process using GitHub/Skara, I find that there is one use case which works considerably worse than before. It is when you want to backport a set of patches that must be pushed together. Imagine you have a patch, then a build fix and then maybe another test fix. So as to not break builds and tests, you will want to push them together in one go. You could now add those 3 commits into one PR. But when you integrate, the 3 commits get squashed which is contrary to the usual way of backporting which tries to preserve individual commits. Alternatively, you could file 3 separate PRs. This, however, often bears the problem that the PRs might be dependent on each other. So any individual backport PR could possibly only be opened and reviewed after its predecessor was integrated. Which will leave the repo in a bad state for a while.
So what can we do here? Shall we change the paradigm and allow more squashing? Or did you already think of a better workflow? I think there is a feature of Skara called dependent PRs. Could that be used here? Or could maybe the backport bot recognize individual commits to preserve?
Thanks in advance for sharing your thoughts.
More information about the skara-dev