+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 wrote:
>
> Hi,
>
> On Wed, Nov 21, 2018 at 11:06 AM Roman Shaposhnik
> wrote:
> >
> > On Fri, Nov 16,
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.
Hi,
On Wed, Nov 21, 2018 at 11:06 AM Roman Shaposhnik wrote:
>
> On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski wrote:
> >
> >
> >
> > > On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz
> > > wrote:
> > >
> > >
> > > I see this as a two-level thing:
> > >
> > > a) The source release is an Act
On Wed, Nov 14, 2018 at 11:32 PM Daniel Shahaf wrote:
>
> 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
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
+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
On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski wrote:
>
>
>
> > On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz
> > 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,
> On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz
> 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
On Thu, Oct 25, 2018 at 5:25 AM Julian Hyde 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
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
Myrle Krantz wrote on Wed, Nov 14, 2018 at 17:19:35 +0100:
> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf
> 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
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
Hi -
Sent from my iPhone
> On Nov 14, 2018, at 11:33 AM, Julian Hyde 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
+1 to everything Mark Thomas said.
On Wed, Nov 14, 2018 at 3:08 AM Mark Thomas 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
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
On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf
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
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 wrote:
>
> Myrle Krantz wrote on Wed, 14 Nov 2018 12:24 +0100:
>> I had understood the reason that the foundation only officially supports
>> source
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
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 wrote:
>
> I had understood the reason that the foundation only officially supports
> source releases to be the fear of undetected malware in the release
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
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
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
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
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
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:
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
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
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
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
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-unsubscr...@incubator.apache.org
For additional commands, e-mail:
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
> wrote:
>
> Hi,
>
>> On Tue, Nov 6, 2018 at 11:07 PM David Nalley wrote:
>> ... To my
Hi,
On Tue, Nov 6, 2018 at 11:07 PM David Nalley 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
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
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
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
>
On Thu, Oct 25, 2018 at 9:39 PM Greg Stein wrote:
>
> On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde 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
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
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" wrote:
On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde wrote:
> Jim, you’re
On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde 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
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.
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
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
+1. That distinction is important. The ASF, and our projects, release source
code.
> On Oct 25, 2018, at 6:39 AM, Greg Stein wrote:
>
> Those are "convenience binaries" ... not "binary releases".
>
> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende
> wrote:
>
>> While I agree that binary
Those are "convenience binaries" ... not "binary releases".
On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende
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
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
On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde 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
> On Oct 24, 2018, at 8:25 PM, Julian Hyde 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
> On Oct 24, 2018, at 8:25 PM, Julian Hyde 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
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
49 matches
Mail list logo
