flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Very high FlexJS installer error rate (98+%)
Date Mon, 20 Oct 2014 21:14:10 GMT
On Oct 20, 2014 2:10 PM, "Justin Mclean" <justin@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.

Wait for 72 hours?

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message