<orcnote> below, -----Original Message----- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Wednesday, October 22, 2014 21:37 To: general@incubator.apache.org Subject: Re: Convenience Binary Policy
On Tue, Oct 21, 2014 at 5:57 AM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Mon, Oct 20, 2014 at 10:26 PM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > >>> P.S.: Why anyone would think voting on binaries makes any kind of sense >>> around here is, of course, a different question. I can't even begin to >>> count the number of times it's been pointed out that binaries are not >>> Apache releases. >> >> And yet that issue keeps rearing its ugly head. Given the amount >> of traffic I've seen around clarifying some finer (and not so fine) >> points of release/licensing implication it is about time we start >> an FAQ on that. Me thinks at least. > > We have several release FAQs spread across the ASF, though -- which, taken > together, are comprehensive beyond the point of excess. > > The problem is that we lack a concise policy document. That's where the "ASF > release policy codification proposal" as worked through on legal-discuss a few > months ago is supposed to help. > > http://s.apache.org/aGm > https://github.com/rectang/asfrelease > > It's delayed because I got swamped but it seems that the need has not > diminished. It would be really nice if you/we could finish this. That said, I still maintain, that focusing exclusively on source releases will simplify our life greatly. IOW, Apache FOO version x.y.z can only designate a source release. I understand the need of projects like OO to provide binaries of some sort, I just don't understand why do they have to be 'blessed' by ASF. Once source gets built and packaged a whole new set of issues kick in. I don't think the foundation is well prepared to deal with those. We might as well admit it explicitly. <orcnote> That's fine. However the Apache OpenOffice project has an important need to establish the provenance and integrity of the end-user binary distributions it makes. There are an incredible variety of poseur builds that are distributed by third parties for the purpose of embedding adware. These also pose as "official" releases, including all of the links to support, pinging for updates, etc. When folks come with complaints, the project lists refer them to the authentic builds that the project curates. This is a significant portion of support requests to users @oo.a.o and dev @oo.a.o. Now that there is code-signing for the Windows (and Mac?) builds, this is going to become easier to fend off. Having the binary distros available from the operating-system "store" applications will provide further safeguards. It is true that the package systems of *nix systems is helpful in terms of authenticity and sourcing of OS-integrated builds and their updates. There is no such source for 80% of the community of Apache OpenOffice users. Before, that community was served by Sun, Oracle, Novell, and IBM. Now, but for the Apache OpenOffice project and The Document Foundation, there are no prominent, responsible parties for distributions to the Windows and Mac communities of users. I do agree that this can be considered a project-specific arrangement and does not need to be under ASF governance as strictly as for source distributions, so long as the "more-than-merely-convenient" binary distributions do not reflect badly on the foundation. Guidance would still be helpful, since there are many projects and podlings need some touchstone to encourage good behavior in this area. </orcnote> Thanks, Roman. P.S. To be super explicit: I'm not saying that binary artifacts should be banned, rather that a binary artifact compiled by a member of a project is no different from one compiled by RedHat or Debian and thus requires no special treatment whatsoever. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
