incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <>
Subject Re: How to review so-called "binary releases"?
Date Wed, 21 Nov 2018 13:55:19 GMT
You could split the review in 2 emails

1. Vote as ASF on the release of the source tgz artifact and release
2. Ask for a review on the publishing of a binary artifact based on the source tgz from email
vote #1 (this is not a ASF Vote, just a request for review a binary) this email of course
would be after email #1 is vote closed    .

- Carlos Santana

> On Nov 20, 2018, at 11:03 PM, Julian Hyde <> wrote:
> +1 to what Bertrand wrote. Solves the problem very neatly. Thank you, Bertrand.
> It goes a long way towards answering my original question, because “What should voters
check for when reviewing binary artifacts?” is now a matter for each PMC, not a matter for
the Foundation.
> +1 to Roman’s suggestion to make it part of policy.
> If we follow Bertrand’s semantics then the semantics of a vote are a little more complex
than before. The voter is voting on the release (consisting only of source artifacts), an
act of the Foundation, and the binary artifacts, an act of the PMC. It would be extremely
helpful if there were a template for the text of the vote email that release managers you
use, if they so chose. Roman, could you include such a template the the revised release policy?
> Julian
>> On Nov 20, 2018, at 7:05 PM, Roman Shaposhnik <> wrote:
>> On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski < <>>
>>>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <>
>>>> I see this as a two-level thing:
>>>> a) The source release is an Act of the Foundation, it is what the
>>>> foundation produces
>>>> b) For the binaries, the PMC states that it thinks they are good and
>>>> declares that the published digests and signatures are the correct
>>>> ones. The Foundation does not state anything about them - use at your
>>>> own risk but in practice that risk is very low if the PMC members
>>>> collectively recommend using them.
>>>> That's not very different from what other open source projects do - we
>>>> need a) for our legal shield but b) is exactly like random open source
>>>> projects operate.
>>>> You have to trust an open source project when you use their binaries,
>>>> and you can use digests and signatures to verify that those binaries
>>>> are the same that everyone else uses - I don't think anyone provides
>>>> more guarantees than that, except when you pay for someone to state
>>>> that those binaries are good.
>>>> If people agree with this view we might need to explain this better,
>>>> "unofficial" does not mean much, this two-level view might be more
>>>> useful.
>>> Agree 100%. Thx for very clearly and accurately describing all this.
>> +1 to this as well.
>> In fact, I love it so much that I'd like to have it published as part of our
>> official guide:
>> <>
>> Any objections?
>> Thanks,
>> Roman.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: <>
>> For additional commands, e-mail: <>

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

View raw message