incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <wadechand...@apache.org>
Subject Re: How to review so-called "binary releases"?
Date Thu, 15 Nov 2018 03:22:12 GMT
IMO something real is missing from this whole conversation.

Does the ASF want to have successful projects? Honest question time. Would Tomcat have been
successful if there had been source only downloads with no “official" runnable software?
Were all those users for all those years compiling their own? No. They downloaded clearly
official binaries. Does this page tomcat.apache.org tell an internet wonderer BEWARE…the
binaries are not official? What about this one https://tomcat.apache.org/download-90.cgi …
pretty sure the sources are the last thing on the page.

Was Maven successful because everyone built it? No. They downloaded what is clearly considered
“official” binaries. This site http://maven.apache.org … what does it point out…unofficial
binaries? No…download, install, run.

NetBeans…not going to make it here on “unofficial" binary releases funny business. What
company wants someone installing that on their system? Security policies anyone? Sorry, just
the truth.

httpd benefited from Linux distros binary distribution in this sense of releases as source,
but if everyone had to “build” their httpd servers, it would not have been the success
it has been; I think it is irrefutable. It’s success was not based on a bunch of admins
who are not software engineers building it, nor was it built on web developers building C
binaries; some of us maybe building ISAPI and NSAPI modules; that’s been a bit.

This whole conversation is missing a crucial point, and it is does Apache want to continue
to be successful? And, do folks really understand how it has been successful to date? It wasn’t
just those of us who contribute code. It was also people using that code, and most of those
folks did not compile it.

Read this whole thread to this point. Does it even make sense? Is there a clear answer? It
is just as confusing to this point as when the question was asked.

It is still a bunch of indirect dancing around of how the users need binaries, but some language
needs to be there to make sure they (users) understand it is unofficial, and not really from
Apache like the source code, but some how “convenience” from “some magic place". It
leaves off the one point that really matters in the end; users using software makes successful
projects and brings and retains donations; simple calculation. Do people use untrusted software?
Not in commercial settings. I think this is exactly why “binary releases are NOT endorsed
by ASF” will not fly very far.

There is a lot of time and resources wrapped up in these type conversations as well as Apache
projects. Real clear guidance seems a must, and it has to be “real” and honest about what
the decision means for successful projects.

Thank you,

Wade



> On Nov 13, 2018, at 3:49 PM, Roman Shaposhnik <roman@shaposhnik.org> 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?
> 
> 
> Thanks,
> Roman.
> On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf <d.s@daniel.shahaf.name <mailto:d.s@daniel.shahaf.name>>
wrote:
>> 
>> 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-unsubscribe@incubator.apache.org <mailto:general-unsubscribe@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <mailto:general-help@incubator.apache.org>
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <mailto:legal-discuss-unsubscribe@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org <mailto:legal-discuss-help@apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message