Proposal: use backports for working with release stabilization repositories

[Erik Duveblad]

Hi all,

this is a proposal to change the process for how we work with commits that
should be applied to _both_ the main-line repository (jdk [0]) and a release
stabilization repository (e.g. jdk19 [1], jdk20 [2]).

The current process we are using today consist of contributors first creating
a pull request targeting the release stabilization repository (e.g. jdk20).
Jesper will then periodically merge changes from the release stabilization
repository to the main-line (jdk) repository. If the merge contains
commits that should *only* be applied to the release stabilization repository,
then those commits have to be backed out [3] from the main-line repository.
The process of Jesper periodically merging changes from the release
stabilization repository to the main-line repository is sometimes referred to as
"forward porting". For more information on the current process, see the
section on "Forward Ports" in the OpenJDK Developer's Guide [4].

I propose that we change to use backports for working with the release
stabilization repositories. With this new process contributors would first
create a pull request targeting the main-line (jdk) repository. Once the
pull request has been reviewed and integrated into the main-line repository
contributors will backport the commit to the release stabilization repository
(e.g. jdk20). The backport can be created in numerous ways but most
contributors will likely use Skara's [5] "/backport" command [6] to create the
backport. For changes that should *only* go into the release stabilization
repository, contributors will create a pull request targeting the release
stabilization repository. Many of you will recognize this process as being
essentially the same one that is being used for backporting changes to update
releases (modulo JBS labels, approvals, etc.).

All the relevant Skara tooling supporting this proposal has been in place for a
long time and is being used by other OpenJDK projects. With this new process we no
longer have to care about backing out release stabilization specific commits
from the main-line repository, there is a much lower risk of issues being introduced
due to incorrect merges and the backport process has proven itself when used by
other OpenJDK projects.

I suggest that we adopt this proposal for JDK 21. 

Please see below for some common questions and answers:
- Q: How can we ensure that no contributor forgets to backport a commit to the
     release stabilization repository?
- A: An e-mail reminder will be sent to jdk-dev [7] prior to entering the
     rampdown phase two (RDP 2) [8] and release candidate (RC) [8] phases. The
     e-mail will contain a link to a JBS [6] query that contributors can click to
     view issues that they have fixed in the main-line repository that are
     applicable to being backported.

     For example, prior to entering RDP 2 for a release an e-mail will be sent
     to jdk-dev with a JBS query that shows a user the P3 issues he or she
     has fixed in the main-line repository since the release stabilization
     repository was created that has *not* been backported to the release
     stabilization repository. Every contributor can read through their own
     list to verify that they haven't forgotten to backport any P3 issues
     before the release enters RDP 2.

- Q: What happens with tags created in the release stabilization repository?
- A: They will be pushed to the main-line repository by the Skara bots. Note that
     only the tags, and the commits they refer to, will be pushed to the main-line
     repository. The commits referred to by the tags will *not* be merged into the
     "master" branch in the main-line repository.

- Q: Will "clean" backports [10] have to be re-reviewed?
- A: Yes. Skara [5] has a feature where "clean" backports can be configured
     (per repository) to be allowed to be integrated without a review. This is
     feature is utilized by some projects in OpenJDK. For the JDK project and for
     release stabilization repositories this feature will be turned off, meaning
     that all backports will require reviews (regardless whether they are
     "clean" or not).

- Q: Can someone other than the original contributor do the backport?
- A: Yes, this is fully supported by Skara. This often happens when an developer
     sponsors a bugfix from a newer contributor who is not yet a committer, and
     that bugfix should be backported to an older release. In that case the
     sponsor is often the one doing the backport.

If this proposal is accepted then information about this process will be added
to the OpenJDK Developer's Guide [11] and to JEP 3 [8]. Please let me know if you have
any feedback, comments or questions!

Thanks,
Erik

[0]:  https://git.openjdk.org/jdk
[1]:  https://git.openjdk.org/jdk19
[2]:  https://git.openjdk.org/jdk20
[3]:  https://openjdk.org/guide/#backing-out-a-change
[4]:  https://openjdk.org/guide/#forward-ports
[5]:  https://openjdk.org/projects/skara/
[6]:  https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/backport
[7]:  jdk-dev at openjdk.org
[8]:  https://openjdk.org/jeps/3
[9]:  https://bugs.openjdk.org
[10]: https://wiki.openjdk.org/display/SKARA/Backports#Backports-Terminology
[11]: https://openjdk.org/guide