incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: How to review so-called "binary releases"?
Date Thu, 25 Oct 2018 17:36:53 GMT

Since binaries are provided as a convenience with no official standing, it doesn't matter
if the "binaries" are "verified" or not.  They could contain a virus or other malware.  Users
take the risks.

However, folks have used the policy you reference to come up with several checks such as:

1) Does the binary run (and pass tests)?
2) Is the list of files the same as the results of building the source package?
3) Do the LICENSE and NOTICE contain the required information from bundled binaries?
4) Do the JAR files contain the correct LICENSE and NOTICE files for the content of the JARs.


On 10/25/18, 10:25 AM, "Julian Hyde" <> wrote:

    Jim, you’re re-iterating the premise of my question. In the context of my question,
it doesn’t matter what these things are called. But we need to know how reviewers are to
handle them.
    Since I asked the original question, I have found the following policy[1]:
    > The Apache Software Foundation produces open source software. All
    > releases are in the form of the source materials needed to make
    > changes to the software being released.
    > As a convenience to users that might not have the appropriate tools to
    > build a compiled version of the source, binary/bytecode packages MAY
    > be distributed alongside official Apache releases. In all such cases, the
    > binary/bytecode package MUST have the same version number as the
    > source release and MUST only add binary/bytecode files that are the
    > result of compiling that version of the source code release and its
    > dependencies.
    This policy clarifies what these things may contain. I still need clarification on what
is the responsibility of a reviewer. I propose:
    1. Reviewers have no way to verify the contents of the binaries and therefore they have
to trust that the release manager has built them according to the documented release process.
    2. Reviewers should check that the binaries contain LICENSE and NOTICE files compatible
with that is believed to be in the binaries.
    > On Oct 25, 2018, at 4:48 AM, Jim Jagielski <> wrote:
    > +1. That distinction is important. The ASF, and our projects, release source code.
    >> On Oct 25, 2018, at 6:39 AM, Greg Stein <> wrote:
    >> Those are "convenience binaries" ... not "binary releases".
    >> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <>
    >> wrote:
    >>> While I agree that binary artifacts are for convenience purposes, if one
    >>> searches  our dist folder they will find lots of projects with binary
    >>> releases.
    >>> When reviewing binary archives we need to make sure that the license file
    >>> is updated with the shiped dependencies licenses appropriately and that
    >>> they are all compatible with the Apache License (notice file might also
    >>> need to be updated).
    >>> On Thu, Oct 25, 2018 at 05:38 Greg Stein <> wrote:
    >>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <>
    >>>>> ...
    >>>>> As a reviewer, how am I to vote on this release candidate?
    >>>> You do NOT vote on binary artifacts. Since you cannot release binaries,
    >>> you
    >>>> should not put the Foundation's imprimatur on those artifacts (and as
    >>>> Member, that is what your vote represents).
    >>>>> Should I vote -1 because the RC contains binaries?
    >>>> Vote on the source artifacts only. Clarify that your vote does not apply
    >>> to
    >>>> the binaries.
    >>>> Cheers,
    >>>> -g
    >>> --
    >>> Sent from my Mobile device
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail:
    > For additional commands, e-mail:
    To unsubscribe, e-mail:
    For additional commands, e-mail:

View raw message