<orcnote> below,
-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@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 <marvin@rectangular.com> wrote:
> On Mon, Oct 20, 2014 at 10:26 PM, Roman Shaposhnik <roman@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-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
|