How to review so-called "binary releases"?

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

How to review so-called "binary releases"?

Julian Hyde-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Dave Fisher-5


> On Oct 24, 2018, at 8:25 PM, Julian Hyde <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Dave Fisher-5
In reply to this post by Julian Hyde-3


> On Oct 24, 2018, at 8:25 PM, Julian Hyde <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Greg Stein-4
In reply to this post by Julian Hyde-3
On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Luciano Resende
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 <[hidden email]> wrote:

> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Greg Stein-4
Those are "convenience binaries" ... not "binary releases".

On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <[hidden email]>
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 <[hidden email]> wrote:
>
> > On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Jim Jagielski
+1. That distinction is important. The ASF, and our projects, release source code.

> On Oct 25, 2018, at 6:39 AM, Greg Stein <[hidden email]> wrote:
>
> Those are "convenience binaries" ... not "binary releases".
>
> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Julian Hyde-3
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 <[hidden email]> wrote:
>
> +1. That distinction is important. The ASF, and our projects, release source code.
>
>> On Oct 25, 2018, at 6:39 AM, Greg Stein <[hidden email]> wrote:
>>
>> Those are "convenience binaries" ... not "binary releases".
>>
>> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <[hidden email]>
>> 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 <[hidden email]> wrote:
>>>
>>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Alex Harui-2
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" <[hidden email]> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C335f6f5bcaeb4f46779008d63a9ee1f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636760851402047786&amp;sdata=scRmJjXdyQCGA2ymR3H4M4dnx6OKuuF3tMnUv64Kf%2FQ%3D&amp;reserved=0
   
    > On Oct 25, 2018, at 4:48 AM, Jim Jagielski <[hidden email]> wrote:
    >
    > +1. That distinction is important. The ASF, and our projects, release source code.
    >
    >> On Oct 25, 2018, at 6:39 AM, Greg Stein <[hidden email]> wrote:
    >>
    >> Those are "convenience binaries" ... not "binary releases".
    >>
    >> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende <[hidden email]>
    >> 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 <[hidden email]> wrote:
    >>>
    >>>> On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde <[hidden email]> 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: [hidden email]
    > For additional commands, e-mail: [hidden email]
    >
   
   
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Justin Mclean-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Greg Stein-4
In reply to this post by Julian Hyde-3
On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Alex Harui-2
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" <[hidden email]> wrote:

    On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Julian Hyde-3
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 <[hidden email]> 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" <[hidden email]> wrote:
>
>    On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

David Nalley
In reply to this post by Greg Stein-4
On Thu, Oct 25, 2018 at 9:39 PM Greg Stein <[hidden email]> wrote:

>
> On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Daniel Shahaf-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Cédric Champeau
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Justin Mclean
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
Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Bertrand Delacretaz
In reply to this post by David Nalley
Hi,

On Tue, Nov 6, 2018 at 11:07 PM David Nalley <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Carlos Santana
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 <[hidden email]> wrote:
>
> Hi,
>
>> On Tue, Nov 6, 2018 at 11:07 PM David Nalley <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to review so-called "binary releases"?

Jim Jagielski
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: [hidden email]
For additional commands, e-mail: [hidden email]

123