RFR: 8327389: Remove use of HOTSPOT_BUILD_USER

Magnus Ihse Bursie ihse at openjdk.org
Thu Mar 7 17:09:54 UTC 2024


On Wed, 6 Mar 2024 18:01:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I agree that it is good to get rid of this. However, the reason it has stuck around for so long is, eh, that it has been around for so long, so it is a bit unclear what or who could be relying on this.
> 
> The example I know is to get a signal that test infrastructures actually picked up my ad-hoc binary build, not some other build from somewhere else. Maybe we should revisit the `git describe` hash idea we kicked along for a while now: https://bugs.openjdk.org/browse/JDK-8274980?focusedId=14452017 -- which would cover that case too.

That bug was resolved with a different patch; presumably it conflated several issues.

There is an inherent conflict with creating a version string that is very much up-to-date and includes ephemeral build data, and creating a robustly reproducible build. If this patch were to remove HOTSPOT_BUILD_USER, and we would later on store `git describe` in the version string, I'm not sure we actually gained anything in terms of reproducability. :-(

As I see it, given this PR, we have a few different options:

1) We can agree that stable and robust reproducibility trumps any automatic inclusion of build situation metadata, and accept this PR and drop the idea of using `git describe`

2) We can agree that reproducibility has its limits, and we need to include (technically irrelevant) metadata in builds to facilitate development. This means dropping this PR since it is used to verify that the correct build was tested, and possibly also adding `git describe` later on.

3) We can agree to disagree about reproducibility limits, but accept that HOTSPOT_BUILD_USER is silly, and accept this PR, but open a separate JBS issue to discuss if adding `git describe` is desirable, and if it can be done in an opt-in manner, with the understanding that it might not be added if we can't agree on it.

4) We can agree to disagree about reproducibility limits, but accept that HOTSPOT_BUILD_USER is silly, and accept this PR, but require that we first implement a substitute functionality using `git describe`, before we can get rid of HOTSPOT_BUILD_USER.

My personal preference would be 3) above, but I am willing to accept any of the paths.

@gnu-andrew and @shipilev, what do you think? I recon you are the one most opinionated about this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984021748


More information about the build-dev mailing list