bq. My stance is that if we're going to publish something, it should be good, or we shouldn't publish it at all.
I agree On Tue, Aug 15, 2017 at 2:57 AM, Steve Loughran <ste...@hortonworks.com> wrote: > > > 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: mapreduce-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org > >
