You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Andrew Wang <an...@cloudera.com> on 2017/07/31 23:18:54 UTC
Are binary artifacts are part of a release?
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.
Best,
Andrew
On Mon, Jul 31, 2017 at 3:56 PM, Chris Douglas <cd...@apache.org> wrote:
> On Mon, Jul 31, 2017 at 3:02 PM, Konstantin Shvachko
> <sh...@gmail.com> wrote:
> > For the packaging, here is the exact phrasing from the sited
> release-policy
> > document relevant to binaries:
> > "As a convenience to users that might not have the appropriate tools to
> > build a compiled version of the source, binary/bytecode packages MAY be
> > distributed alongside official Apache releases. In all such cases, the
> > binary/bytecode package MUST have the same version number as the source
> > release and MUST only add binary/bytecode files that are the result of
> > compiling that version of the source code release and its dependencies."
> > I don't think my binary package violates any of these.
>
> +1 The PMC VOTE applies to source code, only. If someone wants to
> rebuild the binary tarball with native libs and replace this one,
> that's fine.
>
> My reading of the above is that source code must be distributed with
> binaries, not that we omit the source code from binary releases... -C
>
> > But I'll upload an additional tar.gz with native bits and no src, as you
> > guys requested.
> > Will keep it as RC0 as there is no source code change and it comes from
> the
> > same build.
> > Hope this is satisfactory.
> >
> > Thanks,
> > --Konstantin
> >
> > On Mon, Jul 31, 2017 at 1:53 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> >> I agree with Brahma on the two issues flagged (having src in the binary
> >> tarball, missing native libs). These are regressions from prior
> releases.
> >>
> >> As an aside, "we release binaries as a convenience" doesn't relax the
> >> quality bar. The binaries are linked on our website and distributed
> through
> >> official Apache channels. They have to adhere to Apache release
> >> requirements. And, most users consume our work via Maven dependencies,
> >> which are binary artifacts.
> >>
> >> http://www.apache.org/legal/release-policy.html goes into this in more
> >> detail. A release must minimally include source packages, and can also
> >> include binary artifacts.
> >>
> >> Best,
> >> Andrew
> >>
> >> On Mon, Jul 31, 2017 at 12:30 PM, Konstantin Shvachko <
> >> shv.hadoop@gmail.com> wrote:
> >>
> >>> To avoid any confusion in this regard. I built RC0 manually in
> compliance
> >>> with Apache release policy
> >>> http://www.apache.org/legal/release-policy.html
> >>> I edited the HowToReleasePreDSBCR page to make sure people don't use
> >>> Jenkins option for building.
> >>>
> >>> A side note. This particular build is broken anyways, so no worries
> there.
> >>> I think though it would be useful to have it working for testing and
> as a
> >>> packaging standard.
> >>>
> >>> Thanks,
> >>> --Konstantin
> >>>
> >>> On Mon, Jul 31, 2017 at 11:40 AM, Allen Wittenauer <
> >>> aw@effectivemachines.com
> >>> > wrote:
> >>>
> >>> >
> >>> > > On Jul 31, 2017, at 11:20 AM, Konstantin Shvachko <
> >>> shv.hadoop@gmail.com>
> >>> > wrote:
> >>> > >
> >>> > > https://wiki.apache.org/hadoop/HowToReleasePreDSBCR
> >>> >
> >>> > FYI:
> >>> >
> >>> > If you are using ASF Jenkins to create an ASF release
> >>> > artifact, it's pretty much an automatic vote failure as any such
> >>> release is
> >>> > in violation of ASF policy.
> >>> >
> >>> >
> >>>
> >>
> >>
>
Re: Are binary artifacts are part of a release?
Posted by Ravi Prakash <ra...@gmail.com>.
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 <st...@hortonworks.com>
wrote:
>
> > On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <an...@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
>
>
Re: Are binary artifacts are part of a release?
Posted by Ravi Prakash <ra...@gmail.com>.
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 <st...@hortonworks.com>
wrote:
>
> > On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <an...@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
>
>
Re: Are binary artifacts are part of a release?
Posted by Ravi Prakash <ra...@gmail.com>.
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 <st...@hortonworks.com>
wrote:
>
> > On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <an...@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
>
>
Re: Are binary artifacts are part of a release?
Posted by Ravi Prakash <ra...@gmail.com>.
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 <st...@hortonworks.com>
wrote:
>
> > On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <an...@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
>
>
Re: Are binary artifacts are part of a release?
Posted by Steve Loughran <st...@hortonworks.com>.
> On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <sh...@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 <sh...@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 <an...@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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Steve Loughran <st...@hortonworks.com>.
> On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <sh...@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 <sh...@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 <an...@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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Steve Loughran <st...@hortonworks.com>.
> On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <sh...@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 <sh...@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 <an...@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Steve Loughran <st...@hortonworks.com>.
> On 15 Aug 2017, at 07:14, Andrew Wang <an...@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 <sh...@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 <sh...@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 <an...@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
Re: Are binary artifacts are part of a release?
Posted by Andrew Wang <an...@cloudera.com>.
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 <sh...@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 <sh...@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 <an...@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.)
>> >
>> >
>>
>>
>
Re: Are binary artifacts are part of a release?
Posted by Andrew Wang <an...@cloudera.com>.
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 <sh...@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 <sh...@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 <an...@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.)
>> >
>> >
>>
>>
>
Re: Are binary artifacts are part of a release?
Posted by Andrew Wang <an...@cloudera.com>.
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 <sh...@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 <sh...@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 <an...@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.)
>> >
>> >
>>
>>
>
Re: Are binary artifacts are part of a release?
Posted by Andrew Wang <an...@cloudera.com>.
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 <sh...@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 <sh...@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 <an...@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.)
>> >
>> >
>>
>>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <sh...@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/
> 201111.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 <an...@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.)
> >
> >
>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <sh...@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/
> 201111.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 <an...@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.)
> >
> >
>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <sh...@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/
> 201111.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 <an...@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.)
> >
> >
>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <sh...@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/
> 201111.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 <an...@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.)
> >
> >
>
>
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
... that doesn't contradict anything I said.
> On Jul 31, 2017, at 7:23 PM, Konstantin Shvachko <sh...@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/201111.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 <an...@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
... that doesn't contradict anything I said.
> On Jul 31, 2017, at 7:23 PM, Konstantin Shvachko <sh...@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/201111.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 <an...@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
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
... that doesn't contradict anything I said.
> On Jul 31, 2017, at 7:23 PM, Konstantin Shvachko <sh...@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/201111.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 <an...@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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
... that doesn't contradict anything I said.
> On Jul 31, 2017, at 7:23 PM, Konstantin Shvachko <sh...@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/201111.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 <an...@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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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/201111.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 <an...@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.)
>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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/201111.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 <an...@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.)
>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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/201111.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 <an...@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.)
>
>
Re: Are binary artifacts are part of a release?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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/201111.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 <an...@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.)
>
>
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 31, 2017, at 4:18 PM, Andrew Wang <an...@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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 31, 2017, at 4:18 PM, Andrew Wang <an...@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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 31, 2017, at 4:18 PM, Andrew Wang <an...@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Are binary artifacts are part of a release?
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 31, 2017, at 4:18 PM, Andrew Wang <an...@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