+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 <ro...@shaposhnik.org> wrote: > > On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: >> >> >> >>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz >>> <bdelacre...@codeconsult.ch> wrote: >>> >>> >>> 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: > http://www.apache.org/legal/release-policy.html#compiled-packages > <http://www.apache.org/legal/release-policy.html#compiled-packages> > > Any objections? > > Thanks, > Roman. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > <mailto:general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: general-h...@incubator.apache.org > <mailto:general-h...@incubator.apache.org>
