incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: How to review so-called "binary releases"?
Date Wed, 14 Nov 2018 19:35:42 GMT
+1 to everything Mark Thomas said.
On Wed, Nov 14, 2018 at 3:08 AM Mark Thomas <markt@apache.org> wrote:
>
> On 13/11/2018 20:49, Roman Shaposhnik wrote:
> > Personally, given the amount of binary releases that are distributed off of
> > our very own infrastructure (and I'm not even counting our namespace
> > on things like Docker hub -- I'm just talking about the INFRA we run) I don't
> > think that the argument "binary releases are NOT endorsed by ASF" will
> > fly very far.
> >
> > I think the best defense for us is to, perhaps, position them as UGC, but
> > given the practices around existing PMC I don't think that would be easy to
> > do.
> >
> > So the question really boils down to -- how much of a liability this could
> > potentially be for us?
>
> Applying the usual test of "What issues have we seen in the last 20
> years?" I can't think of any that have been specific to a binary release.
>
> Of the issues I can recall with releases since I have been involved at
> the ASF (and I'm sketchy on the details because issues are few and far
> between and I haven't gone looking in the archives):
>
> 1. Dependencies with inappropriate licenses. Perhaps more likely with
> binary releases because they tend to ship with more dependencies but I
> don't recall this ever being more than "Whoops. Tell the users. Do a new
> release to fix it. Be more careful in future. Carry on." for either
> binary or source releases.
>
> 2. Copyright infringement. The only instance I can recall of this was a)
> related to a source release and b) invalid because the accusing party
> had actually originally copied "their" source from us and removed our
> license headers. If anything, I think issue is less likely with a binary
> release.
>
> 3. Download traffic. Some binaries are large and much more likely to
> cause infrastructure issues if the mirror network is not used correctly.
> Infra has monitoring in place to a) identify issues and b) stop them
> causing outages.
>
> So overall, the liability looks to be well within what we are already
> managing. I don't see anything that concerns me. Unless I have missed
> something.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message