incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: How to review so-called "binary releases"?
Date Tue, 06 Nov 2018 22:06:50 GMT
On Thu, Oct 25, 2018 at 9:39 PM Greg Stein <gstein@gmail.com> wrote:
>
> On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <jhyde@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message