The issue was discussed on several occasions in the past. Took me a while to dig this out as an example: http://mail-archives.apache.org/mod_mbox/hadoop-general/201111.mbox/%3C4EB0827C.6040204%40apache.org%3E
Doug Cutting: "Folks should not primarily evaluate binaries when voting. The ASF primarily produces and publishes source-code so voting artifacts should be optimized for evaluation of that." Thanks, --Konst On Mon, Jul 31, 2017 at 4:51 PM, Allen Wittenauer <a...@effectivemachines.com> wrote: > > > On Jul 31, 2017, at 4:18 PM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > > Forking this off to not distract from release activities. > > > > I filed https://issues.apache.org/jira/browse/LEGAL-323 to get clarity > on the matter. I read the entire webpage, and it could be improved one way > or the other. > > > IANAL, my read has always lead me to believe: > > * An artifact is anything that is uploaded to dist.a.o and > repository.a.o > * A release consists of one or more artifacts ("Releases > are, by definition, anything that is published beyond the group that owns > it. In our case, that means any publication outside the group of people on > the product dev list.") > * One of those artifacts MUST be source > * (insert voting rules here) > * They must be built on a machine in control of the RM > * There are no exceptions for alpha, nightly, etc > * (various other requirements) > > i.e., release != artifact .... it's more like release = > artifact * n . > > Do you have to have binaries? No (e.g., Apache SpamAssassin has > no binaries to create). But if you place binaries in dist.a.o or > repository.a.o, they are effectively part of your release and must follow > the same rules. (Votes, etc.) > >
