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 IBM STSM @csantanapr > On Nov 20, 2018, at 11:03 PM, Julian Hyde <jh...@apache.org> 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 <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> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
