[External] : Backporting a set of patches in a single commit

[Kevin Rushforth]

The only drawback I'm aware of is the bit of extra noise caused by the 
automatically created "pr/NNNN" branches. If you don't have a dependent 
PR (which most aren't in my experience), then you can ignore it. If you 
do, then the branch is there and ready for you to use.

I will look for a write-up, but I don't see one, so I don't know for 
sure whether Erik H finished docuementing it. The best source of 
documentation I know of is the "New Skara feature: dependent pull 
requests" [1] email that Erik H sent in March announcing the feature.

If you want us to enable it, we can enable this some time next week.

-- Kevin

[1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-March/004528.html


On 7/22/2021 2:37 PM, Langer, Christoph wrote:
>
> Hi Kevin,
>
> 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?
>
> Thanks
>
> Christoph
>
> *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
>
> Hi Christoph,
>
> 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.
>
> -- Kevin
>
> 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.
>
>     Best regards
>
>     Christoph
>