hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Are binary artifacts are part of a release?
Date Tue, 15 Aug 2017 09:57:24 GMT

> On 15 Aug 2017, at 07:14, Andrew Wang <andrew.wang@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.hadoop@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 <
>> aw@effectivemachines.com> wrote:
>>> ... that doesn't contradict anything I said.
>>>> On Jul 31, 2017, at 7:23 PM, Konstantin Shvachko <shv.hadoop@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 <
>>> aw@effectivemachines.com> wrote:
>>>>> On Jul 31, 2017, at 4:18 PM, Andrew Wang <andrew.wang@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

View raw message