IMO, all of your quotes refer to source releases. The binaries are not an act of the foundation. There might be more flexibility. Any other plan that requires propagation to dist won’t make Om’s talk simply because of mirror propagation time, not to mention voting.
I’ll ask on general@ to see if we need an exception and can get one. -Alex On 10/20/14, 2:09 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: >HI, > >> Would you object to the Installer pointing to binaries with Jburg added >>to >> them on some non-ASF server as the FlexJS 0.0.2 install? > >Yes I would. We can't be seen (from a users point of view) to be >distributing software that looks like it comes from ASF but it actually >comes from elsewhere.There are all sorts of security and trust issues >there for starters, but more importantly it is clearly against Apache >policy to do so. > >Apache has a distribution policy [1] for many good reasons including most >importantly the legal protection of the people involved (including the >board). The only place for general releases is on a.o/dist [2]. Note that >the PMC chair is responsible for what goes into /dist [3] and that the >source package must be sufficient to build any binary artifacts >associated with the release. Releases must be approved by majority vote >(ie 3+1 and no -1s) [4] and only voted on releases can be placed on dist >[5]. > >The correct thing to do as per Apache release policy would be: >1. Remove the 0.01 and 0.02 FlexJS from the installer, keep the FlexJS >Dev build in there. Optional but IMO we shouldn't keep giving users a bad >experience. >2. Branch 0.02 (and possible 0.01 if we still want that to show up in the >installer), change the build process to package Jberg, alter the NOTICE >file and the installer file. Vote and release.This would be fairly >straight forward and the vote should pass at the first RC given the >minimal changes. >3. Update the installer to include the new release(s). >4. Work on releasing 0.03, quite some time has passed and many changes >since the 0.02 release > >This sums it up quite clearly. [6] >"Under no circumstances are unapproved builds a substitute for releases. >If this policy seems inconvenient, then release more often." > >Thanks, >Justin > >1.http://www.apache.org/dev/release.html#why >2. http://www.apache.org/dev/release.html#where-do-releases-go >3. http://www.apache.org/dev/release.html#what-must-every-release-contain >4.http://www.apache.org/dev/release.html#approving-a-release >5.http://www.apache.org/dev/release.html#host-rc >6. http://www.apache.org/dev/release.html#what
