In other words, there are several ways to prove that a binary release is WRONG but (to Greg’s point) there is no way to prove it RIGHT.
As a mentor, I strongly advise against podlings making binary releases, especially for the first release. It’s difficult enough to get L&N correct for source releases, and when a binary release is being make at the same time with necessarily different L&N, the PPMC tend to get hopelessly confused. Bundling artifacts is very common in the Java world, where shading is a best practice and is made very easy by maven. Julian > On May 10, 2018, at 9:06 AM, sebb <seb...@gmail.com> wrote: > > On 10 May 2018 at 16:56, Matt Sicker <boa...@gmail.com> wrote: >> I still minimally require proper gpg signatures on binary artifacts. The >> source artifacts are what get far more scrutiny, but the binaries are >> released on apache.org after all. > > +1 > > It may also be possible to verify that the binary package works. > This obviously depends very much on the project. > > In the case of Java code, it's possible to verify that the jars > contain the expected package names. > Also that the META-INF directory contains NOTICE and LICENSE files, etc. > >> On 10 May 2018 at 10:20, Roman Shaposhnik <ro...@shaposhnik.org> wrote: >> >>> On Thu, May 10, 2018 at 4:17 AM, sebb <seb...@gmail.com> wrote: >>>> On 10 May 2018 at 11:37, Greg Stein <gst...@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang <hux...@apache.org> >>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang <willem.ji...@gmail.com> >>>>>> wrote: >>>>>>> Is there any plan for going through the vote process of Binary file? >>>>>> >>>>>> Yes, binaries will also go through the vote process. >>>>> >>>>> >>>>> No. It makes no sense. >>>>> >>>>> There is NO WAY to verify a binary. Even compiling from source to >>> binary on >>>>> your machine, and trying to compare against a target binary will >>> generally >>>>> fail since timestamps are embedded. Or maybe there are different >>> compilers >>>>> being used. >>>>> >>>>> The Foundation *never* votes on binaries, because the Foundation DOES >>> NOT >>>>> RELEASE BINARIES. The Foundation only votes/authorizes/releases source >>>>> code. REPEAT: only source code. >>>>> >>>>> Only source. Which is verifiable. Which has provenance. >>>> >>>> The LICENCE and NOTICE files that accompany the binary artifact are >>>> text, and IMO should be checked against the contents of the binary >>>> artifact. >>>> For example, if the binary bundles jars from other projects, the L&N >>>> need to agree with the bundled contents. >>> >>> +1000! That has been a well established practice in the Incubator and >>> as such I see no reason not to keep following it. >>> >>> In addition to that, a reasonable effort should be put into making sure >>> that the binary bundle doesn't drag in bits with incompatible licenses >>> (such as GPL). That's why verifying LICENSE in the binary bundle >>> is NOT a simple exersize of comparing it to the source bundle. >>> >>> Thanks, >>> Roman. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> > > --------------------------------------------------------------------- > 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
