Julian,
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.
HTH,
-Alex
On 10/25/18, 10:25 AM, "Julian Hyde" <jh...@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. 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.
Julian
[1]
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23compiled-packages&data=02%7C01%7Caharui%40adobe.com%7C335f6f5bcaeb4f46779008d63a9ee1f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636760851402047786&sdata=scRmJjXdyQCGA2ymR3H4M4dnx6OKuuF3tMnUv64Kf%2FQ%3D&reserved=0
> On Oct 25, 2018, at 4:48 AM, Jim Jagielski <j...@jagunet.com> wrote:
>
> +1. That distinction is important. The ASF, and our projects, release
source code.
>
>> On Oct 25, 2018, at 6:39 AM, Greg Stein <gst...@gmail.com> wrote:
>>
>> Those are "convenience binaries" ... not "binary releases".
>>
>> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <luckbr1...@gmail.com>
>> 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 <gst...@gmail.com> wrote:
>>>
>>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
>>>>> ...
>>>>
>>>>> 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
PMC
>>>> 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: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
