> 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

Reply via email to