On Mon, Jul 31, 2017 at 3:02 PM, Konstantin Shvachko <shv.had...@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 <andrew.w...@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.had...@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 < >>> a...@effectivemachines.com >>> > wrote: >>> >>> > >>> > > On Jul 31, 2017, at 11:20 AM, Konstantin Shvachko < >>> shv.had...@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. >>> > >>> > >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
