You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Julian Hyde <jh...@apache.org> on 2018/10/25 03:25:33 UTC
How to review so-called "binary releases"?
It has been said many times that Apache does not do binary releases, only source releases. But users like binary releases (or pre-built binary artifacts, if you prefer), and therefore podlings like to create them.
So, is there any guidance for how to review a release that contains source and binary tar-balls. Take, for example, crail-1.1-rc2[1], which contains both a -src.tar.gz and a -bin.tar.gz.
-rw-rw-r-- 1 jhyde jhyde 28115272 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz
-rw-rw-r-- 1 jhyde jhyde 473 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz.asc
-rw-rw-r-- 1 jhyde jhyde 169 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz.sha512
-rw-rw-r-- 1 jhyde jhyde 1706869 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz
-rw-rw-r-- 1 jhyde jhyde 473 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz.asc
-rw-rw-r-- 1 jhyde jhyde 169 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz.sha512
As a reviewer, how am I to vote on this release candidate? Should I vote -1 because the RC contains binaries? Should I ignore the -bin.tar.gz and just vote based on the -src.tar.gz? Or are there some review steps I should apply to the -bin.tar.gz?
If this policy is documented somewhere, please send me the link, but I couldn’t find it.
Julian
[1] https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Justin Mclean <ju...@me.com>.
hi,
While we don’t officially vote on connivance releases, I usually follow the guidance here [1] and check that they follow at least current licensing policy. That often means that they have different LICENSE and NOTICE files to the source release.
Thanks,
Justin
1. http://www.apache.org/dev/licensing-howto.html#binary
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Julian,
Since binaries are provided as a convenience with no official standing, it doesn't matter if the "binaries" are "verified" or not. They could contain a virus or other malware. Users take the risks.
However, folks have used the policy you reference to come up with several checks such as:
1) Does the binary run (and pass tests)?
2) Is the list of files the same as the results of building the source package?
3) Do the LICENSE and NOTICE contain the required information from bundled binaries?
4) Do the JAR files contain the correct LICENSE and NOTICE files for the content of the JARs.
HTH,
-Alex
On 10/25/18, 10:25 AM, "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. 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.
2. Reviewers should check that the binaries contain LICENSE and NOTICE files compatible with that is believed to be in the binaries.
Julian
[1] https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23compiled-packages&data=02%7C01%7Caharui%40adobe.com%7C335f6f5bcaeb4f46779008d63a9ee1f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636760851402047786&sdata=scRmJjXdyQCGA2ymR3H4M4dnx6OKuuF3tMnUv64Kf%2FQ%3D&reserved=0
> On Oct 25, 2018, at 4:48 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> +1. That distinction is important. The ASF, and our projects, release source code.
>
>> On Oct 25, 2018, at 6:39 AM, Greg Stein <gs...@gmail.com> wrote:
>>
>> Those are "convenience binaries" ... not "binary releases".
>>
>> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <lu...@gmail.com>
>> wrote:
>>
>>> While I agree that binary artifacts are for convenience purposes, if one
>>> searches our dist folder they will find lots of projects with binary
>>> releases.
>>>
>>> When reviewing binary archives we need to make sure that the license file
>>> is updated with the shiped dependencies licenses appropriately and that
>>> they are all compatible with the Apache License (notice file might also
>>> need to be updated).
>>>
>>>
>>> On Thu, Oct 25, 2018 at 05:38 Greg Stein <gs...@gmail.com> wrote:
>>>
>>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
>>>>> ...
>>>>
>>>>> As a reviewer, how am I to vote on this release candidate?
>>>>
>>>>
>>>> You do NOT vote on binary artifacts. Since you cannot release binaries,
>>> you
>>>> should not put the Foundation's imprimatur on those artifacts (and as PMC
>>>> Member, that is what your vote represents).
>>>>
>>>>
>>>>> Should I vote -1 because the RC contains binaries?
>>>>
>>>>
>>>> Vote on the source artifacts only. Clarify that your vote does not apply
>>> to
>>>> the binaries.
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>> --
>>> Sent from my Mobile device
>>>
>
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by David Nalley <da...@gnsa.us>.
On Wed, Nov 14, 2018 at 11:32 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
<snip>
>
> I think Jim and Greg were describing theory, not practice. We can shout
> from the rooftops that We Do Not Release Binaries, but then you have
> download pages like [1] that present binary artifacts on equal footing
> with source artifacts, without even paying lip service by including the
> term "convenience" somewhere.
>
> The PMC in [1] _is_ releasing binaries as official artifacts — possibly
> in contravention of Board policy, but that's neither here nor there:
> users who visit download pages are not expected to know Board policies.
> A user who visits [1] _will_ consider the binary artifacts official,
> because they are presented as such.
>
> If that's an undesirable outcome, then the Board should enforce its
> policy that download pages aren't to present binaries as official
> artifacts. (Which, I think, is what David was getting at.)
>
<snip>
> [1] <http://redacted.apache.org/download.html>. (I won't name and
> shame, sorry. Could someone volunteer his own PMC's download page for
> a case study? I would volunteer Subversion but I think our download
> page is compliant.)
>
Yes, we can say they aren't official, but that denies the reality of
what projects are doing, and how the foundation celebrates them[1].
We also have multiple projects producing binaries, and signing those
binaries with the ASF's code signing keys[2] which we had to jump
through a lot of hoops to verify our identity as being the real Apache
Software Foundation. We have another project about to use the ASF's
corporate Apple Developer account to 'notarize' releases so they are
identified as originating from the ASF.[3]
IMO, we can label them as 'not releases' and put stickers on that say
'unofficial' but the reality is that we are distributing terabytes of
binaries every day from Foundation resources, occasionally even
stamping them with our official signing certificates, and that should
dispel any illusions we have about those not being actions of the
Foundation.
In my opinion as a single IPMC member (and only wearing that
particular hat), if your podling is shipping binaries, you should
review and vote on them. To ignore them seems irresponsible.
--David
[1] https://www.cnbc.com/2014/04/17/globe-newswire-the-apache-software-foundation-announces-100-million-downloads-of-apachetm-openofficetm.html
in which we issue a press release to celebrate that individuals all
over the world downloaded 100 million copies of a binary
"non-release".
[2] https://blogs.apache.org/infra/entry/code_signing_service_now_available
[3] https://lists.apache.org/thread.html/15ef4c390c6eba7ca80836c214b1121681310d44fe79b32f175aedc3@%3Cprivate.openoffice.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Hyde wrote on Wed, Nov 14, 2018 at 11:33:55 -0800:
> The question with which I started this discussion has not been
> answered. Given that a collection of artifacts is up for a vote, and
> those artifacts are a mixture of source and binary artifacts, what is
> a reviewer to do:
>
> 1. Vote -1. The release contains binaries.
>
I'd vote -1 on the binary artifacts only, since I can't review/audit
them, and vote on the source artifacts on their own merits.
> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
>
> 3. Ignore the binaries. Vote only based on the source artifacts, but
> allow the binary artifacts to appear alongside them in
> https://www.apache.org/dist/ (and other places such as Maven Central).
>
> Current policy, for both the incubator and many other projects, seems
> to be 3. Yet this seems to me to contradict statements by Jim and Greg
> that we only produce source releases.
>
I think Jim and Greg were describing theory, not practice. We can shout
from the rooftops that We Do Not Release Binaries, but then you have
download pages like [1] that present binary artifacts on equal footing
with source artifacts, without even paying lip service by including the
term "convenience" somewhere.
The PMC in [1] _is_ releasing binaries as official artifacts — possibly
in contravention of Board policy, but that's neither here nor there:
users who visit download pages are not expected to know Board policies.
A user who visits [1] _will_ consider the binary artifacts official,
because they are presented as such.
If that's an undesirable outcome, then the Board should enforce its
policy that download pages aren't to present binaries as official
artifacts. (Which, I think, is what David was getting at.)
> My favorite is 2. It reflects reality - we DO release binary artifacts
> along with releases, we have to trust the release manager to have not
> compromised the binaries during the build process, but reviewers can
> help by running cursory checks.
Cheers,
Daniel
[1] <http://redacted.apache.org/download.html>. (I won't name and
shame, sorry. Could someone volunteer his own PMC's download page for
a case study? I would volunteer Subversion but I think our download
page is compliant.)
> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Myrle Krantz wrote on Wed, Nov 14, 2018 at 17:19:35 +0100:
> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> > The answer to (1) depends on the build platform and toolchain.
> > Reproducible builds [in the sense of "building the same source twice
> > gives bit-for-bit identical binaries"] can help with it. When the
> > answer is negative, the next question is whether those unauditable
> > artifacts should be carried by ASF mirrors alongside the source
> > artifacts.
> >
>
> So if a project puts in the effort to
> a.) make their build reproducible (which can actually be very difficult to
> do), and
> b.) do a bit-for bid compare on a release across at least two build
> artifacts, created by different people on different machines...
>
> ...would we be willing to see that threat as sufficiently eliminated for
> our purposes? Would we then be willing to "officially" release binaries?
I would say yes.
I would further note that this is a *sufficient* condition, not a
necessary one. Often, binaries are _nearly_ reproducible but not _bit
for bit_ reproducible — for example, they might contain a date in the
RM's timezone, or the RM's uname(1) output, etc. Such differences are
auditable, and it would be reasonable for a PMC member to compare the
proposed binary artifact to one he built locally, see that the
differences are acceptable, and vote +1 on the binary artifact — just
like we do for source artifacts (when we compare tarballs to tags).
Cheers,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Wade Chandler <wa...@apache.org>.
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 <ro...@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 <ma...@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 <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
Re: How to review so-called "binary releases"?
Posted by Wade Chandler <wa...@apache.org>.
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 <ro...@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 <ma...@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 <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
Sent from my iPhone
> On Nov 14, 2018, at 11:33 AM, Julian Hyde <jh...@apache.org> wrote:
>
> The question with which I started this discussion has not been
> answered. Given that a collection of artifacts is up for a vote, and
> those artifacts are a mixture of source and binary artifacts, what is
> a reviewer to do:
>
> 1. Vote -1. The release contains binaries.
>
> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
This is what I do. I’ll build too, but that may not always work on my environment.
Regards,
Dave
>
> 3. Ignore the binaries. Vote only based on the source artifacts, but
> allow the binary artifacts to appear alongside them in
> https://www.apache.org/dist/ (and other places such as Maven Central).
>
> Current policy, for both the incubator and many other projects, seems
> to be 3. Yet this seems to me to contradict statements by Jim and Greg
> that we only produce source releases.
>
> My favorite is 2. It reflects reality - we DO release binary artifacts
> along with releases, we have to trust the release manager to have not
> compromised the binaries during the build process, but reviewers can
> help by running cursory checks.
>
> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).
>
> Julian
>> On Wed, Nov 14, 2018 at 8:19 AM Myrle Krantz <my...@apache.org> wrote:
>>
>> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
>> wrote:
>>
>>> The answer to (1) depends on the build platform and toolchain.
>>> Reproducible builds [in the sense of "building the same source twice
>>> gives bit-for-bit identical binaries"] can help with it. When the
>>> answer is negative, the next question is whether those unauditable
>>> artifacts should be carried by ASF mirrors alongside the source
>>> artifacts.
>>>
>>
>> So if a project puts in the effort to
>> a.) make their build reproducible (which can actually be very difficult to
>> do), and
>> b.) do a bit-for bid compare on a release across at least two build
>> artifacts, created by different people on different machines...
>>
>> ...would we be willing to see that threat as sufficiently eliminated for
>> our purposes? Would we then be willing to "officially" release binaries?
>>
>> Best Regards,
>> Myrle
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
The question with which I started this discussion has not been
answered. Given that a collection of artifacts is up for a vote, and
those artifacts are a mixture of source and binary artifacts, what is
a reviewer to do:
1. Vote -1. The release contains binaries.
2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
3. Ignore the binaries. Vote only based on the source artifacts, but
allow the binary artifacts to appear alongside them in
https://www.apache.org/dist/ (and other places such as Maven Central).
Current policy, for both the incubator and many other projects, seems
to be 3. Yet this seems to me to contradict statements by Jim and Greg
that we only produce source releases.
My favorite is 2. It reflects reality - we DO release binary artifacts
along with releases, we have to trust the release manager to have not
compromised the binaries during the build process, but reviewers can
help by running cursory checks.
I would like to achieve clarity by voting on the 3 alternatives above
(plus any other alternatives people would like to propose).
Julian
On Wed, Nov 14, 2018 at 8:19 AM Myrle Krantz <my...@apache.org> wrote:
>
> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> > The answer to (1) depends on the build platform and toolchain.
> > Reproducible builds [in the sense of "building the same source twice
> > gives bit-for-bit identical binaries"] can help with it. When the
> > answer is negative, the next question is whether those unauditable
> > artifacts should be carried by ASF mirrors alongside the source
> > artifacts.
> >
>
> So if a project puts in the effort to
> a.) make their build reproducible (which can actually be very difficult to
> do), and
> b.) do a bit-for bid compare on a release across at least two build
> artifacts, created by different people on different machines...
>
> ...would we be willing to see that threat as sufficiently eliminated for
> our purposes? Would we then be willing to "officially" release binaries?
>
> Best Regards,
> Myrle
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Myrle Krantz <my...@apache.org>.
On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> The answer to (1) depends on the build platform and toolchain.
> Reproducible builds [in the sense of "building the same source twice
> gives bit-for-bit identical binaries"] can help with it. When the
> answer is negative, the next question is whether those unauditable
> artifacts should be carried by ASF mirrors alongside the source
> artifacts.
>
So if a project puts in the effort to
a.) make their build reproducible (which can actually be very difficult to
do), and
b.) do a bit-for bid compare on a release across at least two build
artifacts, created by different people on different machines...
...would we be willing to see that threat as sufficiently eliminated for
our purposes? Would we then be willing to "officially" release binaries?
Best Regards,
Myrle
Re: How to review so-called "binary releases"?
Posted by Scott O'Bryan <da...@gmail.com>.
What about maven repos? Are those by definition not generally binary releases?
Sent from my iPhone
> On Nov 14, 2018, at 5:12 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Myrle Krantz wrote on Wed, 14 Nov 2018 12:24 +0100:
>> I had understood the reason that the foundation only officially supports
>> source releases to be the fear of undetected malware in the release (like
>> in the Ken Thompson hack).
>>
>> Is that correct? Are we all are in agreement that the probability of that
>> kind of hack is very low?
>>
>> I'd extend that by one step: Isn't the probably of that kind of hack
>> *lower* if we compile our code ourselves, than if we ask our users to do it?
>
> Yes, the problem with binary artifacts is that it's harder to audit them
> to ensure they are not malicious. (For source artifacts that is not a
> problem because every change between successive source releases results
> in a post-commit email and the PMC is assumed to review its commits@
> mailing list.) However, regarding Thompson's _Reflections on Trusting
> Trust_ attack¹, that specific attack is not the primary concern here:
> there's no need for a backdoor to be self-propagating in order to be of
> concern to ASF.
>
> The simple and immediate attack vector is for whoever generates binary
> artifacts that end up on the dist/ tree — usually, the RM — to generate
> them incorrectly, i.e., to build them not from the official source tree
> but from a patched source tree. (This can happen due to any number of
> reasons: bug, malice, coercion…) The concern is then:
>
> 1. Given that it is possible for an RM to generate binary artifacts
> not from the official source, is it feasible for a PMC to review the
> binary artifacts to catch that?
>
> 2. Suppose an RM generates malicious binary artifacts and uploads them
> to the dist/ tree, whence they are then downloaded. Is ASF liable
> for the results?
>
> The answer to (1) depends on the build platform and toolchain.
> Reproducible builds [in the sense of "building the same source twice
> gives bit-for-bit identical binaries"] can help with it. When the
> answer is negative, the next question is whether those unauditable
> artifacts should be carried by ASF mirrors alongside the source
> artifacts.
>
> I don't know what the answer to (2) is. IANAL.
>
> Cheers,
>
> Daniel
>
> ¹ Thompson postulates a self-propagating backdoor in a self-hosted compiler.
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Myrle Krantz wrote on Wed, 14 Nov 2018 12:24 +0100:
> I had understood the reason that the foundation only officially supports
> source releases to be the fear of undetected malware in the release (like
> in the Ken Thompson hack).
>
> Is that correct? Are we all are in agreement that the probability of that
> kind of hack is very low?
>
> I'd extend that by one step: Isn't the probably of that kind of hack
> *lower* if we compile our code ourselves, than if we ask our users to do it?
Yes, the problem with binary artifacts is that it's harder to audit them
to ensure they are not malicious. (For source artifacts that is not a
problem because every change between successive source releases results
in a post-commit email and the PMC is assumed to review its commits@
mailing list.) However, regarding Thompson's _Reflections on Trusting
Trust_ attack¹, that specific attack is not the primary concern here:
there's no need for a backdoor to be self-propagating in order to be of
concern to ASF.
The simple and immediate attack vector is for whoever generates binary
artifacts that end up on the dist/ tree — usually, the RM — to generate
them incorrectly, i.e., to build them not from the official source tree
but from a patched source tree. (This can happen due to any number of
reasons: bug, malice, coercion…) The concern is then:
1. Given that it is possible for an RM to generate binary artifacts
not from the official source, is it feasible for a PMC to review the
binary artifacts to catch that?
2. Suppose an RM generates malicious binary artifacts and uploads them
to the dist/ tree, whence they are then downloaded. Is ASF liable
for the results?
The answer to (1) depends on the build platform and toolchain.
Reproducible builds [in the sense of "building the same source twice
gives bit-for-bit identical binaries"] can help with it. When the
answer is negative, the next question is whether those unauditable
artifacts should be carried by ASF mirrors alongside the source
artifacts.
I don't know what the answer to (2) is. IANAL.
Cheers,
Daniel
¹ Thompson postulates a self-propagating backdoor in a self-hosted compiler.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
+1 to everything Mark Thomas said.
On Wed, Nov 14, 2018 at 3:08 AM Mark Thomas <ma...@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
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
The reason we "only officially" support source code releases is because that is what we produce.
> On Nov 14, 2018, at 6:24 AM, Myrle Krantz <my...@apache.org> wrote:
>
> I had understood the reason that the foundation only officially supports
> source releases to be the fear of undetected malware in the release (like
> in the Ken Thompson hack).
>
> Is that correct? Are we all are in agreement that the probability of that
> kind of hack is very low?
>
> I'd extend that by one step: Isn't the probably of that kind of hack
> *lower* if we compile our code ourselves, than if we ask our users to do it?
>
> Best Regards,
> Myrle
>
> On Wed, Nov 14, 2018 at 12:08 PM Mark Thomas <ma...@apache.org> wrote:
>
>> 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
Re: How to review so-called "binary releases"?
Posted by Myrle Krantz <my...@apache.org>.
I had understood the reason that the foundation only officially supports
source releases to be the fear of undetected malware in the release (like
in the Ken Thompson hack).
Is that correct? Are we all are in agreement that the probability of that
kind of hack is very low?
I'd extend that by one step: Isn't the probably of that kind of hack
*lower* if we compile our code ourselves, than if we ask our users to do it?
Best Regards,
Myrle
On Wed, Nov 14, 2018 at 12:08 PM Mark Thomas <ma...@apache.org> wrote:
> 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
>
>
Re: How to review so-called "binary releases"?
Posted by Mark Thomas <ma...@apache.org>.
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
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
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....@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
> 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
Re: How to review so-called "binary releases"?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> but I just wanted to highlight that we don't have to restrict our reviews to what is legally needed.
Which is the same for source releases i.e. to vote +1 on a release it just has to compile, but tests could still be failing and/or it could not work. With most of the incubator release I vote on I don’t test that it works only that it compiles, I assume the PPMC has done the other bits.
Thanks,
Justin
Re: How to review so-called "binary releases"?
Posted by Cédric Champeau <ce...@gmail.com>.
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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
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....@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
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
The Jim we are in strongly agreement then :-)
Willem
Yes I think that’s the word “DISCLAIMER”, was the concept and idea I was describing.
I think it depends on the binary (ie npm tgz, jar, docker image, dll, executable) and location (website, sftp, maven, npm registry, nuget, etc) on where to put this. Up to each community what’s the best was to make user downloading aware that this DISCLAIMER exist.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 8:10 PM, Willem Jiang <wi...@gmail.com> wrote:
>
> DISCLAIMER
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Willem Jiang <wi...@gmail.com>.
If the binary release is not the official releases, we need to let
people know about it. Adding the DISCLAIMER could help us with that.
For the other binary release such as Maven release, Docker release
how can we introduce the DISCLAIMER for it?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Nov 7, 2018 at 11:59 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
> IMO, that was (and in many cases) still IS a Good Thing... the issue is that it must be made clear that what the ASF releases are source code artifacts. Any binary releases that are done are not official releases of the foundation nor the PMC, but are community provided conveniences.
>
> > On Nov 7, 2018, at 8:14 AM, Carlos Santana <cs...@gmail.com> wrote:
> >
> > Jim
> >
> > What do you think now?
> > Was that a good or bad thing?
> >
> > TLDR; I’m in favor of convenient binaries is just the how they are handled.
> >
> > Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
> >
> > Now in terms of convenience :-)
> > ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
> >
> > ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> > A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> > The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
> >
> >
> >
> > - Carlos Santana
> > @csantanapr
> >
> >> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >>
> >> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
IMO, that was (and in many cases) still IS a Good Thing... the issue is that it must be made clear that what the ASF releases are source code artifacts. Any binary releases that are done are not official releases of the foundation nor the PMC, but are community provided conveniences.
> On Nov 7, 2018, at 8:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> Jim
>
> What do you think now?
> Was that a good or bad thing?
>
> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>
> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>
> Now in terms of convenience :-)
> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>
> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>
>
>
> - Carlos Santana
> @csantanapr
>
>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by ajs6f <aj...@apache.org>.
Another example: for some projects, the most important distribution is via Maven Central. We can distribute source and binary there, of course, but my guess would be that the vast majority of consumers are pulling the binaries and linking directly against them, using source distributions only for UX/UI assistance in their IDEs, and for Apache dependencies they require in an automated build, maybe not even that.
ajs6f
> On Nov 7, 2018, at 10:23 AM, Dave Fisher <da...@comcast.net> wrote:
>
> Hi -
>
> There are some projects where the binary is all the users want. For example, Apache OpenOffice. In that case these binaries are an exception and while on dist they are not mirrored and instead we distribute through SourceForge.
>
> I think if binaries are kept in a separate folder from source then DISCLAIMERs could be required to be added.
>
> To move to a new url would be very disruptive. To tell projects that they can no longer distribute binaries for community convenience would not be a small, reversible change.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
>> On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>>
>> Jim
>>
>> What do you think now?
>> Was that a good or bad thing?
>>
>> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>>
>> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>>
>> Now in terms of convenience :-)
>> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>>
>> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
>> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
>> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>>
>>
>>
>> - Carlos Santana
>> @csantanapr
>>
>>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>>
>>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Paul King <pa...@asert.com.au>.
I also agree that moving to a different URL would be disruptive. In Apache
Groovy, we have a separate directory for the official (source) release as
distinct from the convenience binaries which are in a separate directory. I
think we copied the approach from Apache Ant. Our release notes stress the
official nature of the source release. IANAL, but I'd think such an
approach could be argued as providing a clear distinction between the
artifacts in terms of any potential liability.
Cheers, Paul.
On Thu, Nov 8, 2018 at 1:24 AM Dave Fisher <da...@comcast.net> wrote:
> Hi -
>
> There are some projects where the binary is all the users want. For
> example, Apache OpenOffice. In that case these binaries are an exception
> and while on dist they are not mirrored and instead we distribute through
> SourceForge.
>
> I think if binaries are kept in a separate folder from source then
> DISCLAIMERs could be required to be added.
>
> To move to a new url would be very disruptive. To tell projects that they
> can no longer distribute binaries for community convenience would not be a
> small, reversible change.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
> >
> > Jim
> >
> > What do you think now?
> > Was that a good or bad thing?
> >
> > TLDR; I’m in favor of convenient binaries is just the how they are
> handled.
> >
> > Sorry for my brevity, what I meant is that binaries should not be beside
> next to the source release seating on the same server and giving the same
> guarantees for both type of artifacts (source vs binary).
> >
> > Now in terms of convenience :-)
> > ASF should not block a project of making binaries available to their
> community for what ever purpose they think appropriate (ie nightly, binary
> of a RC, binary of final RC)
> >
> > ASF should provide guidance to the projects to make sure they make their
> communities aware that a source artifact is different from a binary
> artifact.
> > A project for example can put warnings and bold text on the location (ie
> directory, readme, inside the binary, download webpage, wiki etc) where the
> community downloads a copy of the binary.
> > The warning can say this is not a release of the ASF, is just a
> convenient binary “download on your own risk”, we provide sha256 sum and
> maybe the binary is even signed, but best practice is for you to download
> the source and be in control of building the binary.
> >
> >
> >
> > - Carlos Santana
> > @csantanapr
> >
> >> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >>
> >> Just a FYI that in the early days of the ASF (and the httpd project),
> community binaries were a common offering...
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
There are some projects where the binary is all the users want. For example, Apache OpenOffice. In that case these binaries are an exception and while on dist they are not mirrored and instead we distribute through SourceForge.
I think if binaries are kept in a separate folder from source then DISCLAIMERs could be required to be added.
To move to a new url would be very disruptive. To tell projects that they can no longer distribute binaries for community convenience would not be a small, reversible change.
Regards,
Dave
Sent from my iPhone
> On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> Jim
>
> What do you think now?
> Was that a good or bad thing?
>
> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>
> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>
> Now in terms of convenience :-)
> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>
> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>
>
>
> - Carlos Santana
> @csantanapr
>
>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
There are some projects where the binary is all the users want. For example, Apache OpenOffice. In that case these binaries are an exception and while on dist they are not mirrored and instead we distribute through SourceForge.
I think if binaries are kept in a separate folder from source then DISCLAIMERs could be required to be added.
To move to a new url would be very disruptive. To tell projects that they can no longer distribute binaries for community convenience would not be a small, reversible change.
Regards,
Dave
Sent from my iPhone
> On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> Jim
>
> What do you think now?
> Was that a good or bad thing?
>
> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>
> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>
> Now in terms of convenience :-)
> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>
> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>
>
>
> - Carlos Santana
> @csantanapr
>
>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
Jim
What do you think now?
Was that a good or bad thing?
TLDR; I’m in favor of convenient binaries is just the how they are handled.
Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
Now in terms of convenience :-)
ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
ASF should only distribute source
Having binaries/compiled along side of the source is not a good signal and confusing.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 4:24 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> Hi,
>
>> On Tue, Nov 6, 2018 at 11:07 PM David Nalley <da...@gnsa.us> wrote:
>> ... 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....
>
> I tend to agree and would feel *much* more comfortable if binaries
> went to a different place like binaries.apache.org where we can have
> all sort of loud disclaimers.
>
> I don't know how practical that is in terms of our mirroring system,
> and that might make releases a bit more complicated but it would make
> things much clearer IMO.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi,
On Tue, Nov 6, 2018 at 11:07 PM David Nalley <da...@gnsa.us> wrote:
>... 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....
I tend to agree and would feel *much* more comfortable if binaries
went to a different place like binaries.apache.org where we can have
all sort of loud disclaimers.
I don't know how practical that is in terms of our mirroring system,
and that might make releases a bit more complicated but it would make
things much clearer IMO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by David Nalley <da...@gnsa.us>.
On Thu, Oct 25, 2018 at 9:39 PM Greg Stein <gs...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
Sorry to be stupid, since apparently the answer has been repeated “several times already”. But in the real world podlings (and top-level projects) will put directories up for a vote that contain a mixture of source and binary artifacts.
A case in point. Suppose you were asked to vote on https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/ <https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/>
I hear Justin say that he would open the -bin.tar.gz and check its L & N files. And he would check -bin.tar.gz.asc and -bin.tar.gz.sha512.
And Greg seems to be saying that he would ignore those files altogether, and vote solely based on the -src.tar.gz, -src.tar.gz.asc and -src.tar.gz.sha512.
Are both of these approaches consistent with policy?
Julian
> On Oct 25, 2018, at 7:36 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Hi Greg,
>
> I think the fact that LICENSE policy that Justin linked to applies to convenience binaries creates confusion about reviewing binaries.
>
> My 2 cents,
> -Alex
>
> On 10/25/18, 6:39 PM, "Greg Stein" <gs...@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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Greg,
I think the fact that LICENSE policy that Justin linked to applies to convenience binaries creates confusion about reviewing binaries.
My 2 cents,
-Alex
On 10/25/18, 6:39 PM, "Greg Stein" <gs...@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
Re: How to review so-called "binary releases"?
Posted by Greg Stein <gs...@gmail.com>.
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
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
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. 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.
2. Reviewers should check that the binaries contain LICENSE and NOTICE files compatible with that is believed to be in the binaries.
Julian
[1] http://www.apache.org/legal/release-policy.html#compiled-packages
> On Oct 25, 2018, at 4:48 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> +1. That distinction is important. The ASF, and our projects, release source code.
>
>> On Oct 25, 2018, at 6:39 AM, Greg Stein <gs...@gmail.com> wrote:
>>
>> Those are "convenience binaries" ... not "binary releases".
>>
>> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <lu...@gmail.com>
>> wrote:
>>
>>> While I agree that binary artifacts are for convenience purposes, if one
>>> searches our dist folder they will find lots of projects with binary
>>> releases.
>>>
>>> When reviewing binary archives we need to make sure that the license file
>>> is updated with the shiped dependencies licenses appropriately and that
>>> they are all compatible with the Apache License (notice file might also
>>> need to be updated).
>>>
>>>
>>> On Thu, Oct 25, 2018 at 05:38 Greg Stein <gs...@gmail.com> wrote:
>>>
>>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
>>>>> ...
>>>>
>>>>> As a reviewer, how am I to vote on this release candidate?
>>>>
>>>>
>>>> You do NOT vote on binary artifacts. Since you cannot release binaries,
>>> you
>>>> should not put the Foundation's imprimatur on those artifacts (and as PMC
>>>> Member, that is what your vote represents).
>>>>
>>>>
>>>>> Should I vote -1 because the RC contains binaries?
>>>>
>>>>
>>>> Vote on the source artifacts only. Clarify that your vote does not apply
>>> to
>>>> the binaries.
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>> --
>>> Sent from my Mobile device
>>>
>
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1. That distinction is important. The ASF, and our projects, release source code.
> On Oct 25, 2018, at 6:39 AM, Greg Stein <gs...@gmail.com> wrote:
>
> Those are "convenience binaries" ... not "binary releases".
>
> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <lu...@gmail.com>
> wrote:
>
>> While I agree that binary artifacts are for convenience purposes, if one
>> searches our dist folder they will find lots of projects with binary
>> releases.
>>
>> When reviewing binary archives we need to make sure that the license file
>> is updated with the shiped dependencies licenses appropriately and that
>> they are all compatible with the Apache License (notice file might also
>> need to be updated).
>>
>>
>> On Thu, Oct 25, 2018 at 05:38 Greg Stein <gs...@gmail.com> wrote:
>>
>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
>>>> ...
>>>
>>>> As a reviewer, how am I to vote on this release candidate?
>>>
>>>
>>> You do NOT vote on binary artifacts. Since you cannot release binaries,
>> you
>>> should not put the Foundation's imprimatur on those artifacts (and as PMC
>>> Member, that is what your vote represents).
>>>
>>>
>>>> Should I vote -1 because the RC contains binaries?
>>>
>>>
>>> Vote on the source artifacts only. Clarify that your vote does not apply
>> to
>>> the binaries.
>>>
>>> Cheers,
>>> -g
>>>
>> --
>> Sent from my Mobile device
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Greg Stein <gs...@gmail.com>.
Those are "convenience binaries" ... not "binary releases".
On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <lu...@gmail.com>
wrote:
> While I agree that binary artifacts are for convenience purposes, if one
> searches our dist folder they will find lots of projects with binary
> releases.
>
> When reviewing binary archives we need to make sure that the license file
> is updated with the shiped dependencies licenses appropriately and that
> they are all compatible with the Apache License (notice file might also
> need to be updated).
>
>
> On Thu, Oct 25, 2018 at 05:38 Greg Stein <gs...@gmail.com> wrote:
>
> > On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
> > >...
> >
> > > As a reviewer, how am I to vote on this release candidate?
> >
> >
> > You do NOT vote on binary artifacts. Since you cannot release binaries,
> you
> > should not put the Foundation's imprimatur on those artifacts (and as PMC
> > Member, that is what your vote represents).
> >
> >
> > > Should I vote -1 because the RC contains binaries?
> >
> >
> > Vote on the source artifacts only. Clarify that your vote does not apply
> to
> > the binaries.
> >
> > Cheers,
> > -g
> >
> --
> Sent from my Mobile device
>
Re: How to review so-called "binary releases"?
Posted by Luciano Resende <lu...@gmail.com>.
While I agree that binary artifacts are for convenience purposes, if one
searches our dist folder they will find lots of projects with binary
releases.
When reviewing binary archives we need to make sure that the license file
is updated with the shiped dependencies licenses appropriately and that
they are all compatible with the Apache License (notice file might also
need to be updated).
On Thu, Oct 25, 2018 at 05:38 Greg Stein <gs...@gmail.com> wrote:
> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
> >...
>
> > As a reviewer, how am I to vote on this release candidate?
>
>
> You do NOT vote on binary artifacts. Since you cannot release binaries, you
> should not put the Foundation's imprimatur on those artifacts (and as PMC
> Member, that is what your vote represents).
>
>
> > Should I vote -1 because the RC contains binaries?
>
>
> Vote on the source artifacts only. Clarify that your vote does not apply to
> the binaries.
>
> Cheers,
> -g
>
--
Sent from my Mobile device
Re: How to review so-called "binary releases"?
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <jh...@apache.org> wrote:
>...
> As a reviewer, how am I to vote on this release candidate?
You do NOT vote on binary artifacts. Since you cannot release binaries, you
should not put the Foundation's imprimatur on those artifacts (and as PMC
Member, that is what your vote represents).
> Should I vote -1 because the RC contains binaries?
Vote on the source artifacts only. Clarify that your vote does not apply to
the binaries.
Cheers,
-g
Re: How to review so-called "binary releases"?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 21, 2018 at 6:17 PM Phil Steitz <ph...@gmail.com> wrote:
> ...if I understand all of the previous rationale
> for the foundation -> PMC delegation model is that if publishing
> binary releases is an act of a PMC independent of the foundation,
> the PMC members become individually liable for the action...
My original proposal in this thread says:
> ...The PMC states that it thinks they are good and
> declares that the published digests and signatures are the correct
> ones...
The only guarantee that the PMC (and thus the Foundation?) makes is
that the digests and signatures are the right ones. As for the
binaries, it only expresses an opinion that people can decide to trust
or not.
We might need to clarify that with a suitable general disclaimer for
binaries but I think from a responsibilities point of view it can
work.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/20/18 8:17 PM, Roman Shaposhnik wrote:
> On Fri, Nov 16, 2018 at 8:18 AM Phil Steitz <ph...@gmail.com> wrote:
>> On 11/16/18 7:59 AM, Jim Jagielski wrote:
>>>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>>
>>>>
>>>> I see this as a two-level thing:
>>>>
>>>> a) The source release is an Act of the Foundation, it is what the
>>>> foundation produces
>>>>
>>>> b) For the binaries, the PMC states that it thinks they are good and
>>>> declares that the published digests and signatures are the correct
>>>> ones. The Foundation does not state anything about them - use at your
>>>> own risk but in practice that risk is very low if the PMC members
>>>> collectively recommend using them.
>>>>
>>>> That's not very different from what other open source projects do - we
>>>> need a) for our legal shield but b) is exactly like random open source
>>>> projects operate.
>>>>
>>>> You have to trust an open source project when you use their binaries,
>>>> and you can use digests and signatures to verify that those binaries
>>>> are the same that everyone else uses - I don't think anyone provides
>>>> more guarantees than that, except when you pay for someone to state
>>>> that those binaries are good.
>>>>
>>>> If people agree with this view we might need to explain this better,
>>>> "unofficial" does not mean much, this two-level view might be more
>>>> useful.
>>> Agree 100%. Thx for very clearly and accurately describing all this.
>> I agree with the spirit of this, but I am not sure it is actually
>> practical.
> I actually see it exactly the other way around -- the ONLY practical approach
> to this (as was perfectly summed up by Mart T.).
>
>> I will leave it to the lawyers to opine, but is seems to
>> me that either the binaries represent an "act of the foundation" or
>> they don't.
> They don't. In fact, if you read the following carefully it sort of
> says as much:
> http://www.apache.org/legal/release-policy.html#compiled-packages
> I still would like to clarify it some more to be explicitly saying
> what Bertrand said.
>
> To put a slightly different spin on this: the only "act of the
> foundation" is a source
> release. Period. That doesn't change the fact that there may be sort
> of "acts of PMC"
> that have nothing to do with the foundation, but everything to do with PMC being
> on the same page as the community (hence PMC-specific voting rules).
> "Acts of the PMC"
> include, but are not limited to:
> * voting committers in/out
> * producing binary releases
The problem with this, if I understand all of the previous rationale
for the foundation -> PMC delegation model is that if publishing
binary releases is an act of a PMC independent of the foundation,
the PMC members become individually liable for the action. We
definitely do not want this.
Phil
> * producing blog posts
> * publishing documentation
> * ...
> I can easily see that every one of these may require a PMC-specific
> consensus process
> which sometimes will be conducted as a formal VOTE. However, not every
> "Act of the PMC"
> is the "Act of the Foundation". In fact, I know only 3 cases where
> "Act of the PMC" qualifies
> as either itself or as a board input as "Act of the Foundation":
> #1 Producing a Source Release
> #2 Changing the composition of the PMC
> #3 Changing the chair
>
>> If the PMC does not actually stand behind them, they
>> should be separately marked and explicitly excluded from VOTES.
> This I will agree with. Clearly articulating the responsibilities for
> the voters would
> be very useful indeed.
>
>> Many PMCs include them in votes and almost all PMCs publish them
>> alongside the sources. So I think practically speaking many users
>> view them as official releases. If we want to change that, we need
>> to start labeling things differently.
> I think that's where the confusion starts: regardless of what users view them
> as: practically speaking ASF can only stand behind source releases.
>
> With that in mind, I surely hope we invest in education and community outreach
> to drive the above point home and I also surely hope that we do NOT conduct
> that type of outreach in a form of "disallowing binary releases" or some such.
>
>> I will add one more painful anecdote here. I once published (as RM)
>> a binary release that was bad. An "upgrade" to a maven plugin was
>> applied during the runup to the release and the result was a
>> non-functional binary jar. Neither myself or any other PMC members
>> tested the binaries during the vote. This was very bad. Since
>> then, I have started testing all binary releases that I VOTE on. So
>> in answer to the question of "how do I validate" I would personally
>> recommend that as long as PMCs publish binaries, someone should
>> actually test the rolled binary.
> A telling anecdote for sure, but how is it different from publishing a blog
> post or documentation with incorrect instructions? Legally speaking you
> didn't expose that project of yours to any additional risk, did you?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Nov 20, 2018 at 11:49 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Roman Shaposhnik wrote on Tue, Nov 20, 2018 at 19:17:36 -0800:
> > To put a slightly different spin on this: the only "act of the foundation" is
> > a source release. Period. That doesn't change the fact that there may be sort
> > of "acts of PMC" that have nothing to do with the foundation, but everything
> > to do with PMC being on the same page as the community (hence PMC-specific
> > voting rules). "Acts of the PMC" include, but are not limited to:
> > * voting committers in/out
> > * producing binary releases
> > * producing blog posts
> > * publishing documentation
> > * ...
> > I can easily see that every one of these may require a PMC-specific consensus
> > process which sometimes will be conducted as a formal VOTE. However, not
> > every "Act of the PMC" is the "Act of the Foundation". In fact, I know only 3
> > cases where "Act of the PMC" qualifies as either itself or as a board input
> > as "Act of the Foundation":
> > #1 Producing a Source Release
> > #2 Changing the composition of the PMC
> > #3 Changing the chair
>
> There's no such thing as an "Act of the PMC" because the PMC is not
> a legal person.
What part of 'sort of "acts of PMC"' did you not catch?
> It concerns me that VP Legal, of all people, should think otherwise.
It concerns me that some of us here can't read carefully.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Roman Shaposhnik wrote on Tue, Nov 20, 2018 at 19:17:36 -0800:
> To put a slightly different spin on this: the only "act of the foundation" is
> a source release. Period. That doesn't change the fact that there may be sort
> of "acts of PMC" that have nothing to do with the foundation, but everything
> to do with PMC being on the same page as the community (hence PMC-specific
> voting rules). "Acts of the PMC" include, but are not limited to:
> * voting committers in/out
> * producing binary releases
> * producing blog posts
> * publishing documentation
> * ...
> I can easily see that every one of these may require a PMC-specific consensus
> process which sometimes will be conducted as a formal VOTE. However, not
> every "Act of the PMC" is the "Act of the Foundation". In fact, I know only 3
> cases where "Act of the PMC" qualifies as either itself or as a board input
> as "Act of the Foundation":
> #1 Producing a Source Release
> #2 Changing the composition of the PMC
> #3 Changing the chair
There's no such thing as an "Act of the PMC" because the PMC is not
a legal person.
It concerns me that VP Legal, of all people, should think otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <rv...@apache.org>.
On Fri, Nov 16, 2018 at 8:18 AM Phil Steitz <ph...@gmail.com> wrote:
>
> On 11/16/18 7:59 AM, Jim Jagielski wrote:
> >
> >> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> >>
> >>
> >> I see this as a two-level thing:
> >>
> >> a) The source release is an Act of the Foundation, it is what the
> >> foundation produces
> >>
> >> b) For the binaries, the PMC states that it thinks they are good and
> >> declares that the published digests and signatures are the correct
> >> ones. The Foundation does not state anything about them - use at your
> >> own risk but in practice that risk is very low if the PMC members
> >> collectively recommend using them.
> >>
> >> That's not very different from what other open source projects do - we
> >> need a) for our legal shield but b) is exactly like random open source
> >> projects operate.
> >>
> >> You have to trust an open source project when you use their binaries,
> >> and you can use digests and signatures to verify that those binaries
> >> are the same that everyone else uses - I don't think anyone provides
> >> more guarantees than that, except when you pay for someone to state
> >> that those binaries are good.
> >>
> >> If people agree with this view we might need to explain this better,
> >> "unofficial" does not mean much, this two-level view might be more
> >> useful.
> > Agree 100%. Thx for very clearly and accurately describing all this.
>
> I agree with the spirit of this, but I am not sure it is actually
> practical.
I actually see it exactly the other way around -- the ONLY practical approach
to this (as was perfectly summed up by Mart T.).
> I will leave it to the lawyers to opine, but is seems to
> me that either the binaries represent an "act of the foundation" or
> they don't.
They don't. In fact, if you read the following carefully it sort of
says as much:
http://www.apache.org/legal/release-policy.html#compiled-packages
I still would like to clarify it some more to be explicitly saying
what Bertrand said.
To put a slightly different spin on this: the only "act of the
foundation" is a source
release. Period. That doesn't change the fact that there may be sort
of "acts of PMC"
that have nothing to do with the foundation, but everything to do with PMC being
on the same page as the community (hence PMC-specific voting rules).
"Acts of the PMC"
include, but are not limited to:
* voting committers in/out
* producing binary releases
* producing blog posts
* publishing documentation
* ...
I can easily see that every one of these may require a PMC-specific
consensus process
which sometimes will be conducted as a formal VOTE. However, not every
"Act of the PMC"
is the "Act of the Foundation". In fact, I know only 3 cases where
"Act of the PMC" qualifies
as either itself or as a board input as "Act of the Foundation":
#1 Producing a Source Release
#2 Changing the composition of the PMC
#3 Changing the chair
> If the PMC does not actually stand behind them, they
> should be separately marked and explicitly excluded from VOTES.
This I will agree with. Clearly articulating the responsibilities for
the voters would
be very useful indeed.
> Many PMCs include them in votes and almost all PMCs publish them
> alongside the sources. So I think practically speaking many users
> view them as official releases. If we want to change that, we need
> to start labeling things differently.
I think that's where the confusion starts: regardless of what users view them
as: practically speaking ASF can only stand behind source releases.
With that in mind, I surely hope we invest in education and community outreach
to drive the above point home and I also surely hope that we do NOT conduct
that type of outreach in a form of "disallowing binary releases" or some such.
> I will add one more painful anecdote here. I once published (as RM)
> a binary release that was bad. An "upgrade" to a maven plugin was
> applied during the runup to the release and the result was a
> non-functional binary jar. Neither myself or any other PMC members
> tested the binaries during the vote. This was very bad. Since
> then, I have started testing all binary releases that I VOTE on. So
> in answer to the question of "how do I validate" I would personally
> recommend that as long as PMCs publish binaries, someone should
> actually test the rolled binary.
A telling anecdote for sure, but how is it different from publishing a blog
post or documentation with incorrect instructions? Legally speaking you
didn't expose that project of yours to any additional risk, did you?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Mark Thomas <ma...@apache.org>.
On 21/11/2018 23:25, Greg Stein wrote:
> On Wed, Nov 21, 2018 at 11:42 AM Marvin Humphrey <marvin@rectangular.com
> <ma...@rectangular.com>> wrote:
>
> On Sat, Nov 17, 2018 at 6:14 PM Daniel Shahaf
> <d.s@daniel.shahaf.name <ma...@daniel.shahaf.name>> wrote:
>
> That's why I mentioned reproducible builds elsethread ☺
>
>
> If a project were to implement reproducible builds and then ask the
> Foundation to stand behind them, I think that would be a discussion
> worth having. It's a substantial innovation, worth evaluating
> whether it makes a compiled package auditable by a PMC.
>
>
> And to throw a bombshell into the middle of this discussion:
>
> The Foundation produces *signed* binary releases via a service from
> Symantec. Tomcat and OpenMeetings use this service, and maybe
> OpenOffice. MarkT is our most knowledgeable person.
The service has been in use for ~ 4 years across multiple projects.
Apache Commons uses the code signing service to sign the Windows service
wrapper - primarily because Tomcat asked for it to be signed. Not
signing this would probably only impact Tomcat
Tomcat uses the service to sign the Windows installer and it uses the
signed Windows binaries from Commons. Without signing, the user would
sees various ugly warning messages about using and/or installing unsafe
software. Everything would still work without the signing but there is
the reputation risk associated with users always seeing those warnings.
I believe OpenMeetings uses the code signing service to sign their web
client. Without it, the client will not work. Modern browsers refuse to
run unsigned software without significant hoop jumping that means that,
effectively, their client has to be signed.
I believe CouchDB use the service to sign their Windows installer and/or
windows binaries. I believe the project would be in a similar position
to Tomcat if the service was not available.
Uima uses the service to sign JARs. I believe that this is to reduce
warnings when installing in Eclipse. With the signing service the
project would be in a similar position to Tomcat and CouchDB.
I believe Sling uses the service the way way Uima does.
The service has also been requested, but not used, by OpenOffice,
Logging, HTTP Server and River. It is safe to assume that the impact of
removing the service would be minimal on these projects.
> I would imagine these signed binaries would need to be "official
> releases" despite everything we've ever said about binaries 😋
Indeed.
Switching to having an individual release manager sign releases -
effectively with a personal certificate - might be one way to avoid the
'act of the foundation' concern for binaries but I would argue strongly
against that.
One of the main reasons we use the Symantec service is that it does all
of the hard work - the key management - for us. Long experience with the
infra team tells me that - unfortunately - a large number of our
committers are unable to correctly look after their private keys. I've
lost count of the number of times the infra team has found a committer's
private key on ASF infra. I dread to think where else they might have
stored them. Compromise of a committers private key is likely only to be
embarrassing to that committer. Loss of a committer's private key used
to sign binaries downloaded from the ASF is likely to embarrass the ASF
as well. I think the risks to the ASF are far greater with individual
release managers each having their own code signing key than the risks
associated with binaries signed by the code signing service being viewed
as acts of the foundation.
I think some form of solution along the lines of Bertrand's suggestion
is the way to go.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Nov 21, 2018 at 11:42 AM Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Sat, Nov 17, 2018 at 6:14 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
>> That's why I mentioned reproducible builds elsethread ☺
>>
>
> If a project were to implement reproducible builds and then ask the
> Foundation to stand behind them, I think that would be a discussion worth
> having. It's a substantial innovation, worth evaluating whether it makes a
> compiled package auditable by a PMC.
>
And to throw a bombshell into the middle of this discussion:
The Foundation produces *signed* binary releases via a service from
Symantec. Tomcat and OpenMeetings use this service, and maybe OpenOffice.
MarkT is our most knowledgeable person.
I would imagine these signed binaries would need to be "official releases"
despite everything we've ever said about binaries 😋
Cheers,
-g
ps. and frankly, I could also see Legal Affairs saying "stop doing that",
and discuss with the users of the service
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Marvin Humphrey wrote on Wed, 21 Nov 2018 09:42 -0800:
> On Sat, Nov 17, 2018 at 6:14 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> That's why I mentioned reproducible builds elsethread ☺
> >
>
> If a project were to implement reproducible builds and then ask the
> Foundation to stand behind them, I think that would be a discussion worth
> having. It's a substantial innovation, worth evaluating whether it makes a
> compiled package auditable by a PMC.
There are probably a number of PMC's that are _already_ reproducible.
It's just that none of them has asked for its binaries to be considered
official on account of their being reproducible (so the question is, for the
time being, academic).
The reason I think some PMC's are already reproducible is that the
reproducible-builds.org folks have made progress, among other things, on
making their distros reproducible --- for example, the list of Debian
packages that are reproducible is at [1] --- and the required patches
generally get pushed upstream. (For example, Subversion currently is
99% reproducible, and the remaining 1% is mtime differences inside a zip
file, which I find auditable [2].)
Cheers,
Daniel
[1] https://tests.reproducible-builds.org/debian/buster/amd64/index_reproducible.html
[2] https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/diffoscope-results/subversion.html
The package build produces multiple debs, and all but one of them
are bit-for-bit identical; the one that's not so (a) is auditable,
(b) doesn't even get installed on some setups.
(Before anyone asks, the diff output is truncated by the
presentation layer. It's possible to get the full output.)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alex Harui wrote on Wed, 21 Nov 2018 23:27 +0000:
> Is “reproducible” only defined as “binary checksum matches” or can you
> use a disassembler to show the only differences are time stamps?
It is defined as *bit-for-bit identical binaries*. They cmp(1) equal.
https://reproducible-builds.org/docs/definition/
Cheers,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Myrle Krantz <my...@apache.org>.
On Thu, Nov 22, 2018 at 6:25 AM Greg Stein <gs...@gmail.com> wrote:
>
>> My intro to this was at FOSS Backstage this year:
>> https://youtu.be/m0FudIwSuzM
>>
>
> hehe... I read this as "My talk to introduce others to the concept", and
> tuned in. ... Whoops. Now, re-parsing the sentence as "My learning of the
> concept was at ..." :-D
>
Oops! My bad. But it really was a good talk.
: o),
Myrle
Re: How to review so-called "binary releases"?
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Nov 21, 2018 at 11:20 PM Myrle Krantz <my...@apache.org> wrote:
> “Reproducible” means that two people can run the build at different time
> points and on different hardware and get a bit-identical result if they
> start with the same changeset.
>
> My intro to this was at FOSS Backstage this year:
> https://youtu.be/m0FudIwSuzM
>
hehe... I read this as "My talk to introduce others to the concept", and
tuned in. ... Whoops. Now, re-parsing the sentence as "My learning of the
concept was at ..." :-D
Cheers,
-g
Re: How to review so-called "binary releases"?
Posted by Myrle Krantz <my...@apache.org>.
“Reproducible” means that two people can run the build at different time
points and on different hardware and get a bit-identical result if they
start with the same changeset.
My intro to this was at FOSS Backstage this year:
https://youtu.be/m0FudIwSuzM
Best Regards,
Myrle
On Thu, Nov 22, 2018 at 12:27 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> Is “reproducible” only defined as “binary checksum matches” or can you use
> a disassembler to show the only differences are time stamps?
>
>
>
> -Alex
>
>
>
> *From: *Marvin Humphrey <ma...@rectangular.com>
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Wednesday, November 21, 2018 at 9:42 AM
> *To: *Daniel Shahaf <d....@daniel.shahaf.name>
> *Cc: *"legal-discuss@apache.org" <le...@apache.org>
> *Subject: *Re: How to review so-called "binary releases"?
>
>
>
>
>
> On Sat, Nov 17, 2018 at 6:14 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
>
>
> That's why I mentioned reproducible builds elsethread ☺
>
>
>
> If a project were to implement reproducible builds and then ask the
> Foundation to stand behind them, I think that would be a discussion worth
> having. It's a substantial innovation, worth evaluating whether it makes a
> compiled package auditable by a PMC.
>
>
>
> Marvin Humphrey
>
Re: How to review so-called "binary releases"?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Is “reproducible” only defined as “binary checksum matches” or can you use a disassembler to show the only differences are time stamps?
-Alex
From: Marvin Humphrey <ma...@rectangular.com>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Wednesday, November 21, 2018 at 9:42 AM
To: Daniel Shahaf <d....@daniel.shahaf.name>
Cc: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: How to review so-called "binary releases"?
On Sat, Nov 17, 2018 at 6:14 PM Daniel Shahaf <d....@daniel.shahaf.name>> wrote:
That's why I mentioned reproducible builds elsethread ☺
If a project were to implement reproducible builds and then ask the Foundation to stand behind them, I think that would be a discussion worth having. It's a substantial innovation, worth evaluating whether it makes a compiled package auditable by a PMC.
Marvin Humphrey
Re: How to review so-called "binary releases"?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sat, Nov 17, 2018 at 6:14 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
That's why I mentioned reproducible builds elsethread ☺
>
If a project were to implement reproducible builds and then ask the
Foundation to stand behind them, I think that would be a discussion worth
having. It's a substantial innovation, worth evaluating whether it makes a
compiled package auditable by a PMC.
Marvin Humphrey
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Marvin Humphrey wrote on Sat, 17 Nov 2018 09:06 -0800:
> Our source release process, in contrast, is actually pretty robust against
> nation-state level threat agents. Changesets are tracked commit-by-commit,
> and at release time we can diff the expanded source release archive against
> version control. Sneaking a compromise through such a regime without leaving
> an audit trail is risky enough that we hope and expect that determined
> attackers will move on to easier targets.
The regime is only this watertight if developers use their version
control client to review commits. If developers review commits using
their commits@ list, sneaking in a commit can be done by compromising a
committer's credentials (to push the commit) and apmail@hermes or
httpd@eris credentials (to prevent a post-commit email from being
generated). The tarball would still be identical to the tag, but would
equal the sum of commit mails.
Secondly, I would bet that there are projects that don't review their
commits@ list at all. Call it cynicism, but I've seen enough examples
of committers getting OpenSSH's intentionally-obnoxious "Someone may be
mounting an active attack on you right now!" and responding by deleting
their known_hosts files…
All our processes around PGP, SSH, etc are only good if people follow
them. (That is also why requiring PGP-signed commits wouldn't be as
watertight in practice as it is in theory.)
> In contrast, compiled packages **cannot be audited** like source releases can.
> They are opaque. They are not the accumulation of a unbroken chain of audited
> changesets.
That's why I mentioned reproducible builds elsethread ☺
Cheers,
Daniel
P.S. If we were worried about nation-state adversaries we would have
encrypted our security@ mailing lists.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Nov 17, 2018 at 6:06 PM Marvin Humphrey <ma...@rectangular.com> wrote:
> ...Downstream consumers who trust the binary packages we link to are just
> gambling that the release manager's machine has not been compromised...
I agree, with the additional perceived safety that they get in using
the same binaries as others happily do - assuming they check strong
digests and signatures.
I don't think this makes a difference from a legal point of view, but
from a practical point of view that's vaguely better than just using
any random binary.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Nov 16, 2018 at 8:18 AM Phil Steitz <ph...@gmail.com> wrote:
> I will leave it to the lawyers to opine, but is seems to
> me that either the binaries represent an "act of the foundation" or
> they don't. If the PMC does not actually stand behind them, they
> should be separately marked and explicitly excluded from VOTES. Many
> PMCs include them in votes and almost all PMCs publish them
> alongside the sources. So I think practically speaking many users
> view them as official releases. If we want to change that, we need
> to start labeling things differently.
Of course everybody wants $SOMEBODY_ELSE to take on the risk of producing
binaries. Peace of mind: no matter how much money I lose when something goes
wrong, there'll be somebody with deep pockets to sue.
But the the ASF wasn't set up to be that deep-pocketed entity. It's a
501(c)(3) charity with a paltry annual budget of under 2 million dollars -- an
amount utterly dwarfed by the value of the software development the ASF
oversees.
That's why the ASF encourages third parties to produce binaries from our
source releases. There's profit in being the entity which offers contractual
guarantees about the integrity of compiled packages. Companies that step in
to grasp that opportunity are our friends and often sponsor lots of
development, though simply by publishing binaries they are already crucial
contributors in our ecosystem.
The cost for taking on that risk is that you have to run secure build
clusters, which is extremely difficult and expensive to do right -- and for
the ASF itself, effectively impossible. Our software is important enough that
we have to design processes that can withstand nation-state level threat
agents. No build cluster the ASF can assemble will ever meet that test.
Our source release process, in contrast, is actually pretty robust against
nation-state level threat agents. Changesets are tracked commit-by-commit,
and at release time we can diff the expanded source release archive against
version control. Sneaking a compromise through such a regime without leaving
an audit trail is risky enough that we hope and expect that determined
attackers will move on to easier targets.
In contrast, compiled packages **cannot be audited** like source releases can.
They are opaque. They are not the accumulation of a unbroken chain of audited
changesets.
Downstream consumers who trust the binary packages we link to are just
gambling that the release manager's machine has not been compromised.
Misleading them into thinking that the ASF stands behind binaries produced
under such conditions is irresponsible.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, this is one of the documents that implies that PMCs should examine binaries. See the last section.
http://www.apache.org/dev/licensing-howto.html
On 11/16/18, 8:18 AM, "Phil Steitz" <ph...@gmail.com> wrote:
On 11/16/18 7:59 AM, Jim Jagielski wrote:
>
>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>
>>
>> I see this as a two-level thing:
>>
>> a) The source release is an Act of the Foundation, it is what the
>> foundation produces
>>
>> b) For the binaries, the PMC states that it thinks they are good and
>> declares that the published digests and signatures are the correct
>> ones. The Foundation does not state anything about them - use at your
>> own risk but in practice that risk is very low if the PMC members
>> collectively recommend using them.
>>
>> That's not very different from what other open source projects do - we
>> need a) for our legal shield but b) is exactly like random open source
>> projects operate.
>>
>> You have to trust an open source project when you use their binaries,
>> and you can use digests and signatures to verify that those binaries
>> are the same that everyone else uses - I don't think anyone provides
>> more guarantees than that, except when you pay for someone to state
>> that those binaries are good.
>>
>> If people agree with this view we might need to explain this better,
>> "unofficial" does not mean much, this two-level view might be more
>> useful.
> Agree 100%. Thx for very clearly and accurately describing all this.
I agree with the spirit of this, but I am not sure it is actually
practical. I will leave it to the lawyers to opine, but is seems to
me that either the binaries represent an "act of the foundation" or
they don't. If the PMC does not actually stand behind them, they
should be separately marked and explicitly excluded from VOTES. Many
PMCs include them in votes and almost all PMCs publish them
alongside the sources. So I think practically speaking many users
view them as official releases. If we want to change that, we need
to start labeling things differently.
I will add one more painful anecdote here. I once published (as RM)
a binary release that was bad. An "upgrade" to a maven plugin was
applied during the runup to the release and the result was a
non-functional binary jar. Neither myself or any other PMC members
tested the binaries during the vote. This was very bad. Since
then, I have started testing all binary releases that I VOTE on. So
in answer to the question of "how do I validate" I would personally
recommend that as long as PMCs publish binaries, someone should
actually test the rolled binary.
Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
> gi
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/16/18 7:59 AM, Jim Jagielski wrote:
>
>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>
>>
>> I see this as a two-level thing:
>>
>> a) The source release is an Act of the Foundation, it is what the
>> foundation produces
>>
>> b) For the binaries, the PMC states that it thinks they are good and
>> declares that the published digests and signatures are the correct
>> ones. The Foundation does not state anything about them - use at your
>> own risk but in practice that risk is very low if the PMC members
>> collectively recommend using them.
>>
>> That's not very different from what other open source projects do - we
>> need a) for our legal shield but b) is exactly like random open source
>> projects operate.
>>
>> You have to trust an open source project when you use their binaries,
>> and you can use digests and signatures to verify that those binaries
>> are the same that everyone else uses - I don't think anyone provides
>> more guarantees than that, except when you pay for someone to state
>> that those binaries are good.
>>
>> If people agree with this view we might need to explain this better,
>> "unofficial" does not mean much, this two-level view might be more
>> useful.
> Agree 100%. Thx for very clearly and accurately describing all this.
I agree with the spirit of this, but I am not sure it is actually
practical. I will leave it to the lawyers to opine, but is seems to
me that either the binaries represent an "act of the foundation" or
they don't. If the PMC does not actually stand behind them, they
should be separately marked and explicitly excluded from VOTES. Many
PMCs include them in votes and almost all PMCs publish them
alongside the sources. So I think practically speaking many users
view them as official releases. If we want to change that, we need
to start labeling things differently.
I will add one more painful anecdote here. I once published (as RM)
a binary release that was bad. An "upgrade" to a maven plugin was
applied during the runup to the release and the result was a
non-functional binary jar. Neither myself or any other PMC members
tested the binaries during the vote. This was very bad. Since
then, I have started testing all binary releases that I VOTE on. So
in answer to the question of "how do I validate" I would personally
recommend that as long as PMCs publish binaries, someone should
actually test the rolled binary.
Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
> gi
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Willem Jiang <wi...@gmail.com>.
+1 for adding the convenient binaries release check, it could help
lots of incubator projects.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Feb 14, 2019 at 3:00 PM Huxing Zhang <hu...@apache.org> wrote:
>
> Hi,
>
> On Wed, Nov 21, 2018 at 11:06 AM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> > On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski <ji...@jagunet.com> wrote:
> > >
> > >
> > >
> > > > On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> > > >
> > > >
> > > > I see this as a two-level thing:
> > > >
> > > > a) The source release is an Act of the Foundation, it is what the
> > > > foundation produces
> > > >
> > > > b) For the binaries, the PMC states that it thinks they are good and
> > > > declares that the published digests and signatures are the correct
> > > > ones. The Foundation does not state anything about them - use at your
> > > > own risk but in practice that risk is very low if the PMC members
> > > > collectively recommend using them.
> > > >
> > > > That's not very different from what other open source projects do - we
> > > > need a) for our legal shield but b) is exactly like random open source
> > > > projects operate.
> > > >
> > > > You have to trust an open source project when you use their binaries,
> > > > and you can use digests and signatures to verify that those binaries
> > > > are the same that everyone else uses - I don't think anyone provides
> > > > more guarantees than that, except when you pay for someone to state
> > > > that those binaries are good.
> > > >
> > > > If people agree with this view we might need to explain this better,
> > > > "unofficial" does not mean much, this two-level view might be more
> > > > useful.
> > >
> > > Agree 100%. Thx for very clearly and accurately describing all this.
> >
> > +1 to this as well.
>
> +1 for what Bertrand said.
> I have a quick question from a podling's perspective, should the
> decision for release convenient binaries be left to PPMC or IPMC?
>
> >
> > In fact, I love it so much that I'd like to have it published as part of our
> > official guide:
> > http://www.apache.org/legal/release-policy.html#compiled-packages
> >
> > Any objections?
>
> +1 to add it to the documentation, so that we do not have to search
> for mail archives.
> Besides [1], I think it is also better to add it to [2]. I noticed it
> uses "binary distribution" rather than "binary release".
> So may be we should avoid using "binary release".
>
> For how to do the check for binary distribution, I also suggest to add
> it to [3].
> For example:
> If the source release is accompanied with convenient binaries, we should check:
> - Does the LICENSE and NOTICE text exactly represent the contents of
> the distribution they reside in?
> - Does the jar files includes LICENSE/NOTICE/DISCLAIMER?
>
> Correct me if I am wrong.
>
> [1] http://www.apache.org/legal/release-policy.html#compiled-packages
> [2] http://www.apache.org/dev/licensing-howto.html#binary
> [3] https://wiki.apache.org/incubator/IncubatorReleaseChecklist
>
>
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> --
> Best Regards！
> Huxing
>
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Justin Mclean <ju...@me.com>.
Hi,
> I have a quick question from a podling's perspective, should the
> decision for release convenient binaries be left to PPMC or IPMC?
If the binary are based on source that have been approve as an offical releases there are no issues, just take care to comply with branding and trademarks.
If it based on unreleased code then more care needs to be taken, it can’t be offered or advertised outside the developers and needs to be clearly labeled. The important question to ask is “If a user came across this, could they think it was an Apache release?” If the answer is yes then more work needs to be done.
IMO only the PPMC needs to be involved, the IPMC may take a look and suggest room for improvement.
> Besides [1], I think it is also better to add it to [2]. I noticed it
> uses "binary distribution" rather than "binary release”.
Binary distribution would be the correct term.
Thanks,
Justin
Re: How to review so-called "binary releases"?
Posted by Huxing Zhang <hu...@apache.org>.
Hi,
On Wed, Nov 21, 2018 at 11:06 AM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski <ji...@jagunet.com> wrote:
> >
> >
> >
> > > On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> > >
> > >
> > > I see this as a two-level thing:
> > >
> > > a) The source release is an Act of the Foundation, it is what the
> > > foundation produces
> > >
> > > b) For the binaries, the PMC states that it thinks they are good and
> > > declares that the published digests and signatures are the correct
> > > ones. The Foundation does not state anything about them - use at your
> > > own risk but in practice that risk is very low if the PMC members
> > > collectively recommend using them.
> > >
> > > That's not very different from what other open source projects do - we
> > > need a) for our legal shield but b) is exactly like random open source
> > > projects operate.
> > >
> > > You have to trust an open source project when you use their binaries,
> > > and you can use digests and signatures to verify that those binaries
> > > are the same that everyone else uses - I don't think anyone provides
> > > more guarantees than that, except when you pay for someone to state
> > > that those binaries are good.
> > >
> > > If people agree with this view we might need to explain this better,
> > > "unofficial" does not mean much, this two-level view might be more
> > > useful.
> >
> > Agree 100%. Thx for very clearly and accurately describing all this.
>
> +1 to this as well.
+1 for what Bertrand said.
I have a quick question from a podling's perspective, should the
decision for release convenient binaries be left to PPMC or IPMC?
>
> In fact, I love it so much that I'd like to have it published as part of our
> official guide:
> http://www.apache.org/legal/release-policy.html#compiled-packages
>
> Any objections?
+1 to add it to the documentation, so that we do not have to search
for mail archives.
Besides [1], I think it is also better to add it to [2]. I noticed it
uses "binary distribution" rather than "binary release".
So may be we should avoid using "binary release".
For how to do the check for binary distribution, I also suggest to add
it to [3].
For example:
If the source release is accompanied with convenient binaries, we should check:
- Does the LICENSE and NOTICE text exactly represent the contents of
the distribution they reside in?
- Does the jar files includes LICENSE/NOTICE/DISCLAIMER?
Correct me if I am wrong.
[1] http://www.apache.org/legal/release-policy.html#compiled-packages
[2] http://www.apache.org/dev/licensing-howto.html#binary
[3] https://wiki.apache.org/incubator/IncubatorReleaseChecklist
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Best Regards！
Huxing
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
You could split the review in 2 emails
1. Vote as ASF on the release of the source tgz artifact and release
2. Ask for a review on the publishing of a binary artifact based on the source tgz from email vote #1 (this is not a ASF Vote, just a request for review a binary) this email of course would be after email #1 is vote closed .
- Carlos Santana
IBM STSM
@csantanapr
> On Nov 20, 2018, at 11:03 PM, Julian Hyde <jh...@apache.org> wrote:
>
> +1 to what Bertrand wrote. Solves the problem very neatly. Thank you, Bertrand.
>
> It goes a long way towards answering my original question, because “What should voters check for when reviewing binary artifacts?” is now a matter for each PMC, not a matter for the Foundation.
>
> +1 to Roman’s suggestion to make it part of policy.
>
> If we follow Bertrand’s semantics then the semantics of a vote are a little more complex than before. The voter is voting on the release (consisting only of source artifacts), an act of the Foundation, and the binary artifacts, an act of the PMC. It would be extremely helpful if there were a template for the text of the vote email that release managers you use, if they so chose. Roman, could you include such a template the the revised release policy?
>
> Julian
>
>
>> On Nov 20, 2018, at 7:05 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>
>> On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>>>
>>>
>>>
>>>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>>
>>>>
>>>> I see this as a two-level thing:
>>>>
>>>> a) The source release is an Act of the Foundation, it is what the
>>>> foundation produces
>>>>
>>>> b) For the binaries, the PMC states that it thinks they are good and
>>>> declares that the published digests and signatures are the correct
>>>> ones. The Foundation does not state anything about them - use at your
>>>> own risk but in practice that risk is very low if the PMC members
>>>> collectively recommend using them.
>>>>
>>>> That's not very different from what other open source projects do - we
>>>> need a) for our legal shield but b) is exactly like random open source
>>>> projects operate.
>>>>
>>>> You have to trust an open source project when you use their binaries,
>>>> and you can use digests and signatures to verify that those binaries
>>>> are the same that everyone else uses - I don't think anyone provides
>>>> more guarantees than that, except when you pay for someone to state
>>>> that those binaries are good.
>>>>
>>>> If people agree with this view we might need to explain this better,
>>>> "unofficial" does not mean much, this two-level view might be more
>>>> useful.
>>>
>>> Agree 100%. Thx for very clearly and accurately describing all this.
>>
>> +1 to this as well.
>>
>> In fact, I love it so much that I'd like to have it published as part of our
>> official guide:
>> http://www.apache.org/legal/release-policy.html#compiled-packages <http://www.apache.org/legal/release-policy.html#compiled-packages>
>>
>> Any objections?
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
+1 to what Bertrand wrote. Solves the problem very neatly. Thank you, Bertrand.
It goes a long way towards answering my original question, because “What should voters check for when reviewing binary artifacts?” is now a matter for each PMC, not a matter for the Foundation.
+1 to Roman’s suggestion to make it part of policy.
If we follow Bertrand’s semantics then the semantics of a vote are a little more complex than before. The voter is voting on the release (consisting only of source artifacts), an act of the Foundation, and the binary artifacts, an act of the PMC. It would be extremely helpful if there were a template for the text of the vote email that release managers you use, if they so chose. Roman, could you include such a template the the revised release policy?
Julian
> On Nov 20, 2018, at 7:05 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>>
>>
>>
>>> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>
>>>
>>> I see this as a two-level thing:
>>>
>>> a) The source release is an Act of the Foundation, it is what the
>>> foundation produces
>>>
>>> b) For the binaries, the PMC states that it thinks they are good and
>>> declares that the published digests and signatures are the correct
>>> ones. The Foundation does not state anything about them - use at your
>>> own risk but in practice that risk is very low if the PMC members
>>> collectively recommend using them.
>>>
>>> That's not very different from what other open source projects do - we
>>> need a) for our legal shield but b) is exactly like random open source
>>> projects operate.
>>>
>>> You have to trust an open source project when you use their binaries,
>>> and you can use digests and signatures to verify that those binaries
>>> are the same that everyone else uses - I don't think anyone provides
>>> more guarantees than that, except when you pay for someone to state
>>> that those binaries are good.
>>>
>>> If people agree with this view we might need to explain this better,
>>> "unofficial" does not mean much, this two-level view might be more
>>> useful.
>>
>> Agree 100%. Thx for very clearly and accurately describing all this.
>
> +1 to this as well.
>
> In fact, I love it so much that I'd like to have it published as part of our
> official guide:
> http://www.apache.org/legal/release-policy.html#compiled-packages <http://www.apache.org/legal/release-policy.html#compiled-packages>
>
> Any objections?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
>
>
> > On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> >
> >
> > I see this as a two-level thing:
> >
> > a) The source release is an Act of the Foundation, it is what the
> > foundation produces
> >
> > b) For the binaries, the PMC states that it thinks they are good and
> > declares that the published digests and signatures are the correct
> > ones. The Foundation does not state anything about them - use at your
> > own risk but in practice that risk is very low if the PMC members
> > collectively recommend using them.
> >
> > That's not very different from what other open source projects do - we
> > need a) for our legal shield but b) is exactly like random open source
> > projects operate.
> >
> > You have to trust an open source project when you use their binaries,
> > and you can use digests and signatures to verify that those binaries
> > are the same that everyone else uses - I don't think anyone provides
> > more guarantees than that, except when you pay for someone to state
> > that those binaries are good.
> >
> > If people agree with this view we might need to explain this better,
> > "unofficial" does not mean much, this two-level view might be more
> > useful.
>
> Agree 100%. Thx for very clearly and accurately describing all this.
+1 to this as well.
In fact, I love it so much that I'd like to have it published as part of our
official guide:
http://www.apache.org/legal/release-policy.html#compiled-packages
Any objections?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
>
> I see this as a two-level thing:
>
> a) The source release is an Act of the Foundation, it is what the
> foundation produces
>
> b) For the binaries, the PMC states that it thinks they are good and
> declares that the published digests and signatures are the correct
> ones. The Foundation does not state anything about them - use at your
> own risk but in practice that risk is very low if the PMC members
> collectively recommend using them.
>
> That's not very different from what other open source projects do - we
> need a) for our legal shield but b) is exactly like random open source
> projects operate.
>
> You have to trust an open source project when you use their binaries,
> and you can use digests and signatures to verify that those binaries
> are the same that everyone else uses - I don't think anyone provides
> more guarantees than that, except when you pay for someone to state
> that those binaries are good.
>
> If people agree with this view we might need to explain this better,
> "unofficial" does not mean much, this two-level view might be more
> useful.
Agree 100%. Thx for very clearly and accurately describing all this.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
>
> I see this as a two-level thing:
>
> a) The source release is an Act of the Foundation, it is what the
> foundation produces
>
> b) For the binaries, the PMC states that it thinks they are good and
> declares that the published digests and signatures are the correct
> ones. The Foundation does not state anything about them - use at your
> own risk but in practice that risk is very low if the PMC members
> collectively recommend using them.
>
> That's not very different from what other open source projects do - we
> need a) for our legal shield but b) is exactly like random open source
> projects operate.
>
> You have to trust an open source project when you use their binaries,
> and you can use digests and signatures to verify that those binaries
> are the same that everyone else uses - I don't think anyone provides
> more guarantees than that, except when you pay for someone to state
> that those binaries are good.
>
> If people agree with this view we might need to explain this better,
> "unofficial" does not mean much, this two-level view might be more
> useful.
Agree 100%. Thx for very clearly and accurately describing all this.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thu, Oct 25, 2018 at 5:25 AM Julian Hyde <jh...@apache.org> wrote:
> ...is there any guidance for how to review a release that contains source and binary tar-balls..
>... As a reviewer, how am I to vote on this release candidate?...
When that happens I just vote on the source archive and include it's
digest D in my vote - "I am +1 on the release of the source archive
having digest D".
And then just verify the digests and signatures of the binaries,
considering them as attachments to the release, and indicate that I
checked that in my vote.
I see this as a two-level thing:
a) The source release is an Act of the Foundation, it is what the
foundation produces
b) For the binaries, the PMC states that it thinks they are good and
declares that the published digests and signatures are the correct
ones. The Foundation does not state anything about them - use at your
own risk but in practice that risk is very low if the PMC members
collectively recommend using them.
That's not very different from what other open source projects do - we
need a) for our legal shield but b) is exactly like random open source
projects operate.
You have to trust an open source project when you use their binaries,
and you can use digests and signatures to verify that those binaries
are the same that everyone else uses - I don't think anyone provides
more guarantees than that, except when you pay for someone to state
that those binaries are good.
If people agree with this view we might need to explain this better,
"unofficial" does not mean much, this two-level view might be more
useful.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thu, Oct 25, 2018 at 5:25 AM Julian Hyde <jh...@apache.org> wrote:
> ...is there any guidance for how to review a release that contains source and binary tar-balls..
>... As a reviewer, how am I to vote on this release candidate?...
When that happens I just vote on the source archive and include it's
digest D in my vote - "I am +1 on the release of the source archive
having digest D".
And then just verify the digests and signatures of the binaries,
considering them as attachments to the release, and indicate that I
checked that in my vote.
I see this as a two-level thing:
a) The source release is an Act of the Foundation, it is what the
foundation produces
b) For the binaries, the PMC states that it thinks they are good and
declares that the published digests and signatures are the correct
ones. The Foundation does not state anything about them - use at your
own risk but in practice that risk is very low if the PMC members
collectively recommend using them.
That's not very different from what other open source projects do - we
need a) for our legal shield but b) is exactly like random open source
projects operate.
You have to trust an open source project when you use their binaries,
and you can use digests and signatures to verify that those binaries
are the same that everyone else uses - I don't think anyone provides
more guarantees than that, except when you pay for someone to state
that those binaries are good.
If people agree with this view we might need to explain this better,
"unofficial" does not mean much, this two-level view might be more
useful.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
> On Oct 24, 2018, at 8:25 PM, Julian Hyde <jh...@apache.org> wrote:
>
> It has been said many times that Apache does not do binary releases, only source releases. But users like binary releases (or pre-built binary artifacts, if you prefer), and therefore podlings like to create them.
>
> So, is there any guidance for how to review a release that contains source and binary tar-balls. Take, for example, crail-1.1-rc2[1], which contains both a -src.tar.gz and a -bin.tar.gz.
>
> -rw-rw-r-- 1 jhyde jhyde 28115272 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz
> -rw-rw-r-- 1 jhyde jhyde 473 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz.asc
> -rw-rw-r-- 1 jhyde jhyde 169 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz.sha512
> -rw-rw-r-- 1 jhyde jhyde 1706869 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz
> -rw-rw-r-- 1 jhyde jhyde 473 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz.asc
> -rw-rw-r-- 1 jhyde jhyde 169 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz.sha512
>
> As a reviewer, how am I to vote on this release candidate? Should I vote -1 because the RC contains binaries? Should I ignore the -bin.tar.gz and just vote based on the -src.tar.gz? Or are there some review steps I should apply to the -bin.tar.gz?
The source release should be all source code except for some images and other document resources meant for testing,
>
> If this policy is documented somewhere, please send me the link, but I couldn’t find it.
>
> Julian
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/
> ---------------------------------------------------------------------
> 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
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
> On Oct 24, 2018, at 8:25 PM, Julian Hyde <jh...@apache.org> wrote:
>
> It has been said many times that Apache does not do binary releases, only source releases. But users like binary releases (or pre-built binary artifacts, if you prefer), and therefore podlings like to create them.
>
> So, is there any guidance for how to review a release that contains source and binary tar-balls. Take, for example, crail-1.1-rc2[1], which contains both a -src.tar.gz and a -bin.tar.gz.
>
> -rw-rw-r-- 1 jhyde jhyde 28115272 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz
> -rw-rw-r-- 1 jhyde jhyde 473 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz.asc
> -rw-rw-r-- 1 jhyde jhyde 169 Oct 23 11:25 apache-crail-1.1-incubating-bin.tar.gz.sha512
> -rw-rw-r-- 1 jhyde jhyde 1706869 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz
> -rw-rw-r-- 1 jhyde jhyde 473 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz.asc
> -rw-rw-r-- 1 jhyde jhyde 169 Oct 23 11:25 apache-crail-1.1-incubating-src.tar.gz.sha512
>
> As a reviewer, how am I to vote on this release candidate? Should I vote -1 because the RC contains binaries? Should I ignore the -bin.tar.gz and just vote based on the -src.tar.gz? Or are there some review steps I should apply to the -bin.tar.gz?
>
> If this policy is documented somewhere, please send me the link, but I couldn’t find it.
I consider the source release separately from the convenience binary releases.
I am on the Apache OpenOffice PMC where there is a single source release and over 240 binary releases. I vote on the source release and one or two of the pertinent binary releases. EG. I;ll vote on the us-en release but not the pt-br or other language releases.
(BTW- We are about to VOTE for OpenOffice 4.1.6. RC1 now.)
When I do vote the checks are the same except I will attempt to build a source release.
Regards,
Dave
>
> Julian
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/
> ---------------------------------------------------------------------
> 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