On Thu, Oct 25, 2018 at 9:39 PM Greg Stein <gst...@gmail.com> wrote: > > On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <jh...@apache.org> wrote: > > > Jim, you’re re-iterating the premise of my question. In the context of my > > question, it doesn’t matter what these things are called. But we need to > > know how reviewers are to handle them. > > > > Since I asked the original question, I have found the following policy[1]: > > > > > COMPILED PACKAGES > > > > > > The Apache Software Foundation produces open source software. All > > > releases are in the form of the source materials needed to make > > > changes to the software being released. > > > > > > As a convenience to users that might not have the appropriate tools to > > > build a compiled version of the source, binary/bytecode packages MAY > > > be distributed alongside official Apache releases. In all such cases, the > > > binary/bytecode package MUST have the same version number as the > > > source release and MUST only add binary/bytecode files that are the > > > result of compiling that version of the source code release and its > > > dependencies. > > > > This policy clarifies what these things may contain. I still need > > clarification on what is the responsibility of a reviewer. > > > It has been repeated several times already. There is no such thing as > "reviewer" since these are not official releases. So they certainly > shouldn't be voted upon. They are just some binaries hanging out on our > server. > > I propose: > > > > 1. Reviewers have no way to verify the contents of the binaries and > > therefore they have to trust that the release manager has built them > > according to the documented release process. > > > > And this is exactly why they are unofficial. > > -g
Playing devil's advocate for a moment, and primarily picking on Greg since he won't take it personally and hopefully will indulge me. :) 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? To my mind, allowing projects to distribute 'convenience binaries' from our hardware, in a place we say contains releases, and which is occasionally consumed in such a way as to dwarf what we call official releases[1], makes them actions of the Foundation despite our protestations. Even more so since we haven't claimed DMCA Safe Harbor protections as a hosting provider rather than as an entity that publishes its own content. --David [1] Cassandra mistakenly pointed people to a binary deb repo that was running on our TLP boxes - the traffic to that deb repo was responsible for 15% of the total bandwidth consumed by the Foundation for the month or so that it ran in that fashion. No small feat. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
