RFR: 1797: Add support for /backport pull request command

Thomas Stüfe thomas.stuefe at gmail.com
Thu Feb 2 08:28:50 UTC 2023

> > 1. If the `/backport` command is used in an **open** pull request, it
> adds a label `Backport=repo:branch` to the PR. If the PR is later
> integrated, the PR bot scans for backport labels and begins the backporting
> process. To cancel the backport, the user can use `/backport disable repo
> master` to remove the label before the PR is integrated.
> This does not sound desirable. Fixes should undergo some bake time in
> the primary repo before they get backported anywhere. With the current
> situation it is up to the person doing the backport to go to the commit
> in question and know that the commit has been suitable tested/baked.
> David
> -----
I agree with David. Making it easy to downport fresh changes right away is
not something we should encourage.

Yes, there are cases of super-simple fixes that can be backported right
away. But those are the exception. Update releases are *maintenance*
releases with a much larger customer surface than the head release. If
something goes wrong, the impact is large and immediate.

But we only have limited testing resources for update releases. We do our
best, but the mainline is still much better tested. We live with that; we
assume that backports have been exposed in the mainline repo long enough
for issues to surface. Immediate backporting breaks this assumption.

Cheers, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230202/cfa3c7fb/attachment.htm>

More information about the skara-dev mailing list