Add workflow to verify release candidate on multiple systems

[timsaucer]

Which issue does this PR close?

None

Rationale for this change

Thank you to @kevinjqliu for this suggestion to include as part of our workflow

What changes are included in this PR?

This PR adds a manually triggered GitHub Actions workflow to verify release candidates across multiple OS/architecture combinations, and updates the release guide to include this verification note before sending the vote email.

Are there any user-facing changes?

None

[timsaucer]

Excellent idea @kevinjqliu ! I think there are two changes we should make:

• Add note in the file describing that it is a manually run workflow as a hint for future developers
• Add to the release steps to run this workflow before sending the vote email

[kevinjqliu]

I can make the changes above to the release and verify process.

Just a note from ASF perspective; It is allowed to verify releases with cloud machines, but must create release artifacts on personal hardware.

From https://www.apache.org/legal/release-policy.html#owned-controlled-hardware

Must releases be built on hardware owned and controlled by the committer?
Strictly speaking, releases must be verified on hardware owned and controlled by the committer. That means hardware the committer has physical possession and control of and exclusively full administrative/superuser access to. That's because only such hardware is qualified to hold a PGP private key, and the release should be verified on the machine the private key lives on or on a machine as trusted as that.

Practically speaking, when a release consists of anything beyond an archive (e.g., tarball or zip file) of a source control tag, the only practical way to validate that archive is to build it locally; manually inspecting generated files (especially binary files) is not feasible. So, basically, "Yes".

Note: This answer refers to the process used to produce a release artifact from a source control tag. It does not refer to testing that artifact for technical quality.

[kevinjqliu]

@timsaucer Could you update the PR description with something like:

This PR adds a manually triggered GitHub Actions workflow to verify release candidates across multiple OS/architecture combinations, and updates the release guide to include this verification note before sending the vote email.

[kevinjqliu]

As a follow up, I can take a look at how to enable this for Windows (I think it requires a few minor changes to dev/release/verify-release-candidate.sh)

If this is helpful, we can also port it over to other datafusion projects.

[timsaucer]

This is excellent. Thanks again! I'll start merging things after 52.0.0 release finishes, just to keep the history clean.