incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: How to review so-called "binary releases"?
Date Thu, 15 Nov 2018 04:32:10 GMT
Julian Hyde wrote on Wed, Nov 14, 2018 at 11:33:55 -0800:
> 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.

I'd vote -1 on the binary artifacts only, since I can't review/audit
them, and vote on the source artifacts on their own merits.

> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
> 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.

I think Jim and Greg were describing theory, not practice.  We can shout
from the rooftops that We Do Not Release Binaries, but then you have
download pages like [1] that present binary artifacts on equal footing
with source artifacts, without even paying lip service by including the
term "convenience" somewhere.

The PMC in [1] _is_ releasing binaries as official artifacts — possibly
in contravention of Board policy, but that's neither here nor there:
users who visit download pages are not expected to know Board policies.
A user who visits [1] _will_ consider the binary artifacts official,
because they are presented as such.

If that's an undesirable outcome, then the Board should enforce its
policy that download pages aren't to present binaries as official
artifacts.  (Which, I think, is what David was getting at.)

> 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.



[1] <>.  (I won't name and
shame, sorry.  Could someone volunteer his own PMC's download page for
a case study?  I would volunteer Subversion but I think our download
page is compliant.)

> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).

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

View raw message