incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: How to review so-called "binary releases"?
Date Wed, 14 Nov 2018 00:12:42 GMT
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 <dave2wave@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 <csantana23@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 <jim@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
>
>

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