incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: How to review so-called "binary releases"?
Date Mon, 29 Oct 2018 19:12:17 GMT
Sorry to be stupid, since apparently the answer has been repeated “several times already”.
But in the real world podlings (and top-level projects) will put directories up for a vote
that contain a mixture of source and binary artifacts.

A case in point. Suppose you were asked to vote on

I hear Justin say that he would open the -bin.tar.gz and check its L & N files. And he
would check -bin.tar.gz.asc and -bin.tar.gz.sha512.

And Greg seems to be saying that he would ignore those files altogether, and vote solely based
on the -src.tar.gz, -src.tar.gz.asc and -src.tar.gz.sha512.

Are both of these approaches consistent with policy?


> On Oct 25, 2018, at 7:36 PM, Alex Harui <> wrote:
> Hi Greg,
> I think the fact that LICENSE policy that Justin linked to applies to convenience binaries
creates confusion about reviewing binaries.
> My 2 cents,
> -Alex
> On 10/25/18, 6:39 PM, "Greg Stein" <> wrote:
>    On Thu, Oct 25, 2018 at 12:25 PM 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.
>    It has been repeated several times already. There is no such thing as
>    "reviewer" since these are not official releases. So they certainly
>    shouldn't be voted upon. They are just some binaries hanging out on our
>    server.
>    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.
>    And this is exactly why they are unofficial.
>    -g
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message