I’ve been using the reproducibility check provided in the vote email, though I haven’t been able to reproduce a build 100% so far due to some dependency-convergence issues in the Cassandra plugin (go figure, complex dependency tree there), but I’ve mentioned something about this in the vote emails. — Matt Sicker
> On Dec 27, 2023, at 08:10, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Gary, > > On Wed, 27 Dec 2023 at 13:58, Gary Gregory <garydgreg...@gmail.com> wrote: >> Please include whatever instructions you want folks to run in the vote >> email to prove reproducibility. Then at least we can agree on what it >> means to do the reproducibility check and when it passes or fails, >> assuming it's a binary property. > > The steps to check reproducibility are in the vote e-mail: > > # Verify reproduciblity > umask 0022 > unzip *-src.zip -d src > cd src > export > NEXUS_REPO=https://repository.apache.org/content/repositories/orgapachelogging-1254 > sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO > >> A long-standing pet peeve of mine is PMC members (in many projects, >> I'm not singling out Log4j here) that vote on a release candidate >> without stating _what_ they did to check the viability of said >> release. >> >> If this matters, it should be an Apache requirement, which it is not ATM >> AFAIK. > > I agree, there should be some minimal best practices for release > verification. If Apache Security does not want ATM to set some > guidelines, I wouldn't mind if Apache Commons did. > > BTW I cited your vote mail in this thread, mostly because you always > describe what you are checking. > From the votes of some PMC members it is impossible to deduce what was > checked. > > Piotr
