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 wrote:
>
> Hi Gary,
>
> On Wed, 27 Dec 2023 at 13:58, Gary Gregory 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
