While officially binaries are only convenience, it happened several times with Groovy that we downvote a release _because_ of broken binaries. So we integrate them as part of our review process. Basically, we do the usual checks on sources (checksums, signatures, build, ...), but we _also_ check that the convenience binaries work. That means, unzip, try to run the app, play with it, ... Most of this process is automated during the build, there are still a few quirks because of cross-platform testing, but I just wanted to highlight that we don't have to restrict our reviews to what is legally needed.
Le mer. 7 nov. 2018 à 01:55, Daniel Shahaf <d...@daniel.shahaf.name> a écrit : > CC += legal-discuss@ since this really isn't an incubator-specific topic > any > more. The context is precompiled binary artifacts on > https://www.apache.org/dist/. > > David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500: > > So let's assume a PMC (or PPMC) goes through the same process with > > binaries in terms of reviewing, voting on, promoting, and publishing > > to the world a binary release on behalf of the PMC and Foundation. > > Binaries are published to the same location that source tar balls are > > - are featured on download pages provided by the ASF. Perhaps even > > with the situation being that people download the binary artifacts > > from ASF resources tens of thousands, or maybe even millions of times > > more frequently than the source tarballs. > > > > From that scenario I have some questions: > > > > 1. Would a reasonable person (or jury) suspend disbelief long enough > > to consider our protestations that our 'releases' are source only, and > > that as a Foundation we didn't release, propagate, promote, or > > distribute the binaries in question? A rose by any other name..... > > 2. Should the Board be taking an active interest in projects (release > > managers?) who promote and publish their binaries in this manner on > > our hardware? > > 3. Is lack of Board action tantamount to tacit approval of this > > behavior? Can we really claim ignorance? > > 4. Should Infrastructure be actively monitoring and removing binaries > > which find their way to dist.a.o/archive.a.o - especially since our > > header for dist.a.o says that the directories contain releases of > > Apache software? > > 5. Should we be alerting individual release managers that publishing > > convenience binaries exposes them individually to liability? > > 6. What alternative can we offer to projects that want to distribute > binaries? > Can the RM upload precompiled binaries to his https://home.a.o/~availid/ > space? > Can the project's download page link to them as the > primary/canonical/recommended binaries? Can the project's download page > link > to the RM's binaries as one alternative among many (compare > https://subversion.apache.org/packages#windows)? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
