On Fri, 1 May 2026 at 16:24, Gilles Sadowski <[email protected]> wrote: > > Le ven. 1 mai 2026 à 17:07, sebb <[email protected]> a écrit : > > > > On Fri, 1 May 2026 at 12:34, Gilles Sadowski <[email protected]> wrote: > > > > > > Le ven. 1 mai 2026 à 10:22, Alex Herbert <[email protected]> a > > > écrit : > > > > > > > > On Thu, 30 Apr 2026 at 18:12, Rob Tompkins <[email protected]> wrote: > > > > > > > > > Or send a script that properly downloads all the artifacts from nexus > > > > > and > > > > > svn, and computes all the md5 checksums, sha512s, and gpg signatures > > > > > all > > > > > the while scanning across the directory structure. I spent over 80 > > > > > hours on > > > > > my script so that I have time to validate releases. > > > > > > > > > > > > > I agree that manually validating can be time consuming. However we > > > > already > > > > have software tools available to help. > > > > > > > > Regarding the GPG signatures the vote only concerns the 4 release > > > > artifacts. This is no different than any other commons release regarding > > > > verifying signatures. I believe your release helper script will validate > > > > the source and binary distributions as it does for all other commons > > > > releases. > > > > > > > > If you wish to verify the additional Maven artifacts (that are not > > > > official > > > > part of the release) > > > > > > Isn't the validation of the artefacts done by the following? > > > > > > $ svn co https://dist.apache.org/repos/dist/dev/commons/statistics/1.3-RC1 > > > $ cd 1.3-RC1 > > > $ ./signature-validator.sh > > > https://repository.apache.org/content/repositories/orgapachecommons-1933/org/apache/commons/ > > > > > > IIUC, "reproducibility" referred to below is only a check for the > > > RM (to avoid releasing spurious files). > > > > AFAICT the reproducibility check does not ensure that there are no > > spurious (or missing) files in the artifact bundles. > > > > This is because the source artifact is not created from a fresh > > checkout of the source. > > Instead, it is created AFTER building and testing, which can create or > > delete files. > > Sure. You point is interesting in that a useful (?) utility might > be to be able generate the official release bundles _without_ > running the compilation and unit tests (and ensure that they > are the same as those produced after a "regular" build).
It's easier to compare the contents of the source bundle with a fresh checkout of the source tag. > My point, confusingly, was that I don't get what "reproducibility" > has to do with approving a release (of _source_ code). Agreed, I don't think it helps with approval of the source bundle. > Is the problem here that the reviewer does not trust that the RM > produced the convenience artefacts from the same sources? However, we also release binaries, and it is useful to know that others can successfully build equivalent binaries. Unless builds are designed to be reproducible, this is an almost impossible task. As with the source bundle, reproducible builds do not detect missing or spurious files in the binary bundle, but at least they can show that a successful build is not confined to the system used by the RM. > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
