General Retrospective for January 2026 Releases

[adamfarley]

Summary

A retrospective for all efforts surrounding the titular releases.

All community members are welcome to contribute to the agenda via comments below.

This will be a virtual meeting after the release, with at least a week of notice in the #release Slack channel.

On the day of the meeting we'll review the agenda and add a list of actions at the end.

Invited: Everyone.

Time, Date, and URL

Tuesday the 10th of February.
Time: 3pm UK, 10am Ontario
Meeting URL: https://eclipse.zoom.us/j/81872484707?pwd=dGl1QzcrTllWUkNWRUVGNzdYVUx4dz09

Details

Retrospective Owner Tasks (in order):

• Post retro URL in #Release around the start of the new release.
• Wait until most builds are released, with no signs of a respin.
• Announce the retrospective's date + time on #Release a week in advance.
• Host the retrospective:
  • Go through the agenda.
  • Create a list of actions.
• Process each action:
  • Create a "WIP" issue including the source comment.
  • Add the issue to the current iteration.
  • Add an issue link to the action list.
• Create a new retrospective issue for the next release.
• Set a calendar reminder so you remember to do step 1 before the next release.
• Close this issue.

TLDR

Add proposed agenda items as comments below.

[adamfarley]

Solaris

Below are links to Solaris comments in the previous retrospective.

Deferred to this retro because by the end of January we may/should have a better sense of the future of Solaris at Adoptium.

• General Retrospective for September and October 2025 Releases #90 (comment)
• General Retrospective for September and October 2025 Releases #90 (comment)

[smlambert]

Update release checklist:

• to verify release banner is added (instead of adding release banner, since we now have prepopulated 2 yrs of them via Add release banners for next 2 years.. adoptium.net#553)

• banner also removed itself automatically (so the note later in the checklist around removing it can also be changed or removed)

[smlambert]

There is no link in the checklist to instructions on how to "Regenerate The Release Build Pipeline Jobs In Jenkins" though it is described in the releasing guide (https://github.com/adoptium/temurin-build/blob/master/RELEASING.md#release-pipelines-and-jobs-need-to-be-re-generated-with-new-tags-by-the-release-champion).

[andrew-m-leonard]

DryRun had a few issues with aqa-tests master changes not merged into the v1.0.11-release branch, which brings to mind whether we should consider enabling running aqa-tests release branch tests for the EA builds :

• eg. jdk-21.0.10 EA builds running against v1.0.11-release branch AqaVit tests

[smlambert]

Discuss whether we should move the dry run triage into temurin-build repo adoptium/temurin-build#4367 where in past we do it in aqa-tests repo (adoptium/aqa-tests#6664, etc). Continuing to do it in the aqa-tests repo would likely make it easier for searching for existing or intermittent issues...

[smlambert]

Ensure we review PRs in aqa-tests for what needs cherrypicking ahead of launching dry runs (update the checklist item to remind to check this).

[smlambert]

Is code freeze really necessary? It adds several additional steps in the release checklist. Should we just be tagging and using all of the relevant Temurin repos from SHAs/tags (or if necessary branches)?

[smlambert]

• Declare code freeze to ensure stability of build systems and infrastructure during release process : #build and #release slack message: "Code Freeze is now being enabled"

• Enable code freeze bot : Enabling code freeze

These steps should be reversed in the checklist (enable then announce as opposed to announce then enable).

[andrew-m-leonard]

A handful of remote build triggers got stuck with status update Max connection retries errors, issue: adoptium/ci-jenkins-pipelines#1354

[smlambert]

Is the second "regenerate release pipelines" actually necessary, since it has already been done as part of the dry run steps earlier in the checklist with the correct branch names, and the regeneration job has not been rerun since?

[smlambert]

https://bugs.openjdk.org/ now requires a login, making it more difficult for some people to look up if an existing issue has been reported or not

• Note this is not an issue, if you go directly to a specific bug report, so no action needed with this note

[smlambert]

Nice to see the faster execution time of AQAvit test jobs with dynamic agents in place, ~4.5 hours for extended.openjdk now

[andrew-m-leonard]

JCK ReRun facility proving very useful, especially to rerun unstable dev.jck or other sanity/special that might have failed due to a "glitch"

SL/Feb4: we think we can 'enhance' this feature slightly, in that we can also report back on the auto '_rerun' job link, and support (and potentially support remote triggering of that job, which is typically smaller/less tests than the original, as it reruns only failed tests from the original run (failed test targets or test cases depending on number of failures).