incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
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 https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/
<https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/> 

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?

Julian



> On Oct 25, 2018, at 7:36 PM, Alex Harui <aharui@adobe.com.INVALID> 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" <gstein@gmail.com> wrote:
> 
>    On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <jhyde@apache.org> 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]:
>> 
>>> COMPILED PACKAGES
>>> 
>>> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


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