incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: How to review so-called "binary releases"?
Date Wed, 14 Nov 2018 20:42:14 GMT
Hi -

Sent from my iPhone

> On Nov 14, 2018, at 11:33 AM, Julian Hyde <> wrote:
> The question with which I started this discussion has not been
> answered. Given that a collection of artifacts is up for a vote, and
> those artifacts are a mixture of source and binary artifacts, what is
> a reviewer to do:
> 1. Vote -1. The release contains binaries.
> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.

This is what I do. I’ll build too, but that may not always work on my environment.


> 3. Ignore the binaries. Vote only based on the source artifacts, but
> allow the binary artifacts to appear alongside them in
> (and other places such as Maven Central).
> Current policy, for both the incubator and many other projects, seems
> to be 3. Yet this seems to me to contradict statements by Jim and Greg
> that we only produce source releases.
> My favorite is 2. It reflects reality - we DO release binary artifacts
> along with releases, we have to trust the release manager to have not
> compromised the binaries during the build process, but reviewers can
> help by running cursory checks.
> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).
> Julian
>> On Wed, Nov 14, 2018 at 8:19 AM Myrle Krantz <> wrote:
>> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <>
>> wrote:
>>> The answer to (1) depends on the build platform and toolchain.
>>> Reproducible builds [in the sense of "building the same source twice
>>> gives bit-for-bit identical binaries"] can help with it.  When the
>>> answer is negative, the next question is whether those unauditable
>>> artifacts should be carried by ASF mirrors alongside the source
>>> artifacts.
>> So if a project puts in the effort to
>> a.) make their build reproducible (which can actually be very difficult to
>> do), and
>> b.) do a bit-for bid compare on a release across at least two build
>> artifacts, created by different people on different machines...
>> ...would we be willing to see that threat as sufficiently eliminated for
>> our purposes?  Would we then be willing to "officially" release binaries?
>> Best Regards,
>> Myrle
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message