Sorry to be stupid, since apparently the answer has been repeated “several times already”. But in the real world podlings (and top-level projects) will put directories up for a vote that contain a mixture of source and binary artifacts.
A case in point. Suppose you were asked to vote on https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/ <https://dist.apache.org/repos/dist/dev/incubator/crail/1.1-rc2/> I hear Justin say that he would open the -bin.tar.gz and check its L & N files. And he would check -bin.tar.gz.asc and -bin.tar.gz.sha512. And Greg seems to be saying that he would ignore those files altogether, and vote solely based on the -src.tar.gz, -src.tar.gz.asc and -src.tar.gz.sha512. Are both of these approaches consistent with policy? Julian > On Oct 25, 2018, at 7:36 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Hi Greg, > > I think the fact that LICENSE policy that Justin linked to applies to > convenience binaries creates confusion about reviewing binaries. > > My 2 cents, > -Alex > > On 10/25/18, 6:39 PM, "Greg Stein" <gst...@gmail.com> wrote: > > On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <jh...@apache.org> wrote: > >> Jim, you’re re-iterating the premise of my question. In the context of my >> question, it doesn’t matter what these things are called. But we need to >> know how reviewers are to handle them. >> >> Since I asked the original question, I have found the following policy[1]: >> >>> COMPILED PACKAGES >>> >>> The Apache Software Foundation produces open source software. All >>> releases are in the form of the source materials needed to make >>> changes to the software being released. >>> >>> 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. >> >> This policy clarifies what these things may contain. I still need >> clarification on what is the responsibility of a reviewer. > > > It has been repeated several times already. There is no such thing as > "reviewer" since these are not official releases. So they certainly > shouldn't be voted upon. They are just some binaries hanging out on our > server. > > I propose: >> >> 1. Reviewers have no way to verify the contents of the binaries and >> therefore they have to trust that the release manager has built them >> according to the documented release process. >> > > And this is exactly why they are unofficial. > > -g > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org
