> On 15 Aug 2017, at 07:14, Andrew Wang <andrew.w...@cloudera.com> wrote: > > 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 >
Given we publish the artifacts to the m2 repo, which is very much a downstream distribution mechanism. For other redist mechanisms (yum, apt-get) its implicitly handled by whoever manages those repos. > 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.) >>>> >>>> >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
