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.)
>
>

Reply via email to