To close the thread on this, I'll try to summarize the LEGAL JIRA. I wasn't able to convince anyone to make changes to the apache.org docs.
Convenience binary artifacts are not official release artifacts and thus are not voted on. However, since they are distributed by Apache, they are still subject to the same distribution requirements as official release artifacts. This means they need to have a LICENSE and NOTICE file, follow ASF licensing rules, etc. The PMC needs to ensure that binary artifacts meet these requirements. However, being a "convenience" artifact doesn't mean it isn't important. The appropriate level of quality for binary artifacts is left up to the project. An OpenOffice person mentioned the quality of their binary artifacts is super important since very few of their users will compile their own office suite. I don't know if we've discussed the topic of binary artifact quality in Hadoop. My stance is that if we're going to publish something, it should be good, or we shouldn't publish it at all. I think we do want to publish binary tarballs (it's the easiest way for new users to get started with Hadoop), so it's fair to consider them when evaluating a release. Best, Andrew On Mon, Jul 31, 2017 at 8:43 PM, Konstantin Shvachko <shv.had...@gmail.com> wrote: > It does not. Just adding historical references, as Andrew raised the > question. > > On Mon, Jul 31, 2017 at 7:38 PM, Allen Wittenauer < > a...@effectivemachines.com> wrote: > >> >> ... that doesn't contradict anything I said. >> >> > On Jul 31, 2017, at 7:23 PM, Konstantin Shvachko <shv.had...@gmail.com> >> wrote: >> > >> > 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/2011 >> 11.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.) >> > >> > >> >> >
