General Retrospective for March/April 2024 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

Time: 3pm BST, 10am EST.
Date: Tuesday the 7th of May, 2024.
URL: https://eclipse.zoom.us/j/82423919203?pwd=jcs9cimNWYIflSqChjnT5U5Aj62sSx.1
Meeting ID: 824 2391 9203
Passcode: 339984

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.
• Tell Carmen Delgado so they can add this retrospective to the community calendar.
• 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.

[smlambert]

Scary msg when publishing aarch64_mac binaries, believe it did the right thing (pushing 31 artifacts to releases repo, but found 62 and reported UNSTABLE
https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/8424/

dryrun did not indicate any issues to be aware of https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/8423/

[sophia-guo]

#28 (comment)

It happened to all platforms.

The status is unstable as it's counting some of the -ea tagged artifacts, which means the check file needs to update. Maybe we should think is there a better way or automate way to check the numbers?

[jerboaa]

Something went wrong with publishing source tarballs for the Jan 2024 update. See: adoptium/adoptium-support#1003 we should make sure that it's there with some verification for any release.

[sophia-guo]

Also to publish the binary you can try the rerun link at the lower part of page https://ci.adoptium.net/job/build-scripts/job/release-openjdk22-pipeline/5/, which is enabled for this release.

Dry runs are triggered by pipeline job itself. If dry run fails the rerun link would be Dry run RELEASE Publish temurin jdk-22+36 mac x64, which will trigger a dryrun. Otherwise the rerun link would be RELEASE Publish temurin jdk-22+36 mac x64 and no need to do the dryrun.

[smlambert]

Also to publish the binary you can try the rerun link

That is what I clicked to run first the dry run (8423), then the release run (8424). I expected the release checks that we have in place to work, but I guess they do not take into account the presence of the EA artifacts.

By the way, I very much LOVE having the release links available, as I will never get the regex wrong again! Now we just need to update the checks to be a bit more specific and handle gracefully or remove the EA artifacts.

[smlambert]

With new feature release, need to ensure aqa-tests JCK configs updated (and likely shift to using a template that does not require duplicating configs for each new version).

[smlambert]

With new feature release, check if Version List on website needs updating? adoptium/archive1---adoptium.net#1116

[sophia-guo]

That is what I clicked to run first the dry run (8423), then the release run (8424).

A little bit of confused. Dry run was triggered by pipeline and succeeded. Is 8423 for double check?

[smlambert]

A little bit of confused. Dry run was triggered by pipeline and succeeded. Is 8423 for double check?

Yes, and also because I did not find the output from the original dry run quickly

[sophia-guo]

Would it be helpful to add the dry-run build links?

[smlambert]

Downside of everyone and their dog using Grinders for all kinds of good work is that it is more difficult to spot the ones launched to complete release triage. (no action required on this comment, good bookkeeping can cover it, or we advise folks doing dev work to use Grinder_Dev, or some such).

[smlambert]

Would it be helpful to add the dry-run build links?

I think the dryruns for publishing were there to help deal with the great potential for human error, which is essentially removed by the addition of the prepopulated 'quick links' found at the bottom of the parent pipeline job.

If the dryruns did some of the verification that happens during the actual publish (checking the right number of artifacts exist), and subsequently fail or report if there was an issue, they would have a purpose. Without the verification checks happening in the dry run, there seems little need to run an automated dry run.

[smlambert]

The release has been chugging along smoothly enough to allow for development work to continue alongside of it. The unfreezing of master branches in Temurin project also a good thing.

[smlambert]

Triggering the pipeline ahead of the -ga tag was a good call. The upstream -ga tag did not show up until much later (~full day) than we triggered the pipeline (Wed/20th).