Julian Hyde wrote on Wed, Nov 14, 2018 at 11:33:55 -0800: > The question with which I started this discussion has not been > answered. Given that a collection of artifacts is up for a vote, and > those artifacts are a mixture of source and binary artifacts, what is > a reviewer to do: > > 1. Vote -1. The release contains binaries. >
I'd vote -1 on the binary artifacts only, since I can't review/audit them, and vote on the source artifacts on their own merits. > 2. Perform some cursory checks on the binaries (e.g. L&N) and vote > accordingly. > > 3. Ignore the binaries. Vote only based on the source artifacts, but > allow the binary artifacts to appear alongside them in > https://www.apache.org/dist/ (and other places such as Maven Central). > > Current policy, for both the incubator and many other projects, seems > to be 3. Yet this seems to me to contradict statements by Jim and Greg > that we only produce source releases. > I think Jim and Greg were describing theory, not practice. We can shout from the rooftops that We Do Not Release Binaries, but then you have download pages like [1] that present binary artifacts on equal footing with source artifacts, without even paying lip service by including the term "convenience" somewhere. The PMC in [1] _is_ releasing binaries as official artifacts — possibly in contravention of Board policy, but that's neither here nor there: users who visit download pages are not expected to know Board policies. A user who visits [1] _will_ consider the binary artifacts official, because they are presented as such. If that's an undesirable outcome, then the Board should enforce its policy that download pages aren't to present binaries as official artifacts. (Which, I think, is what David was getting at.) > My favorite is 2. It reflects reality - we DO release binary artifacts > along with releases, we have to trust the release manager to have not > compromised the binaries during the build process, but reviewers can > help by running cursory checks. Cheers, Daniel [1] <http://redacted.apache.org/download.html>. (I won't name and shame, sorry. Could someone volunteer his own PMC's download page for a case study? I would volunteer Subversion but I think our download page is compliant.) > I would like to achieve clarity by voting on the 3 alternatives above > (plus any other alternatives people would like to propose). --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
