flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Very high FlexJS installer error rate (98+%)
Date Tue, 21 Oct 2014 17:09:09 GMT

On 10/21/14, 6:35 AM, "Harbs" <harbs.lists@gmail.com> wrote:

>I’m happy to wait for incubator resolution. (Does that give Om enough
>time for his presentation?)
I don’t think we need to wait for a resolution in the sense that they are
going to vote on whether we can modify the binary package or not or
someone will give us official approval.  IMO, it is about whether someone
can give a good reason not to do it.  It doesn’t even have to be written
policy, it just has to convince enough folks that it is a bad idea.

>I’m actually trying to understand the issues involved here.
The problem scenario is quite simple:  You cannot use the Installer to
install FlexJS 0.0.2 (or 0.0.1). The code that fetches downloads of binary
dependencies from SourceForge worked just fine until a couple of weeks
ago.  You can use Ant on the binary package that is on dist/mirrors.  I’m
told that an average of 5 people a day are trying to use the Installer to
install FlexJS.  At the same time we see increased traffic on the FlexJS
downloads page, so I am hopeful that those 5 folks are heading over there
and using Ant to get FlexJS installed.

I had looked into workarounds but didn’t see any easy ones because the
URLs in the FlexJS script are hard coded.  In the main Flex SDK script,
the URLs are in overridable variables so when Flex SDK installs started to
fail because of this SourceForge issue, we worked around it by modifying
the set of URLs loaded by the Flex SDK’s install script.  FlexJS’s install
script can also load a set of URLs, but the URLs in question were
hard-coded into the script and not in variables.  To me, the fact that 5
people a day were getting failures from the Installer was an unfortunate,
but not high priority problem, so I was mostly ignoring it and instead,
spending my time trying to get to a point where I want to release a FlexJS
0.0.3.  I did make enough changes such that the FlexJS Nightly builds
successfully install.
Then Om pointed out that his FlexJS talk at the HTML 5 conference is this
morning and that could cause a surge in the number of folks trying to use
the installer and having their first exposure to Apache and Flex be less
than satisfying.  So I dug a little harder and found that by modifying the
binary package we can get FlexJS 0.0.2 builds to succeed.

Because binary packages are not “acts of the Foundation” and are only
“acts of the individual”, it seemed like it might be ok to update the
binary package the installer uses.  Doing so does not put the foundation
at risk.  None of the sources that get compiled and none of the compiled
result of those sources are being modified, so IMO it is still a viable
FlexJS 0.0.2 binary package, but this is where it gets a bit fuzzy and
therefore controversial.

Even though the release policy documents focus on source releases, there
is plenty of precedent that binary packages must also have correct LICENSE
and NOTICE files for the contents of the package.  The inserting of
jburg.jar into the binary package means that the LICENSE file should
change to notify folks that the binary package isn’t all-Apache.  So in
the most recent binary package I’ve cooked up, there is a modified LICENSE
file.  I suppose in the strictest sense, that is a change to “source”, but
nobody on Incubator has flagged that as a reason we can’t modify the
binary package.  Also, the LICENSE and NOTICE in binary packages are often
not the same as the LICENSE and NOTICE in the source package.  Further,
some binary packages have generated LICENSE and NOTICE files.  The files
are not stored in the project’s SCM in their entirety, only in pieces.
I’m certainly willing to check in the modified LICENSE somewhere in our
SCM before we expose this package to the public if we agree we should do

The additional wrinkle that the Installer adds is that folks who use it do
not actually get a chance to examine the LICENSE and NOTICE in the binary
package before running the rest of the install script.  Instead the
Installer presents license information to the user that the user accepts
by checking some checkboxes.  So, I suppose we could choose not to have a
modified LICENSE in this modified binary package, but maybe folks will
scan the LICENSE post-install, so that’s why I decided to change it.  But
I also changed the set of LICENSE checkboxes the user needs to accept
before continuing the install with the installer, but that is done in an
XML file that is separate from the binary package.

On the incubator thread, the initial responder did say “no vote, not
official”, but after I pointed to some archived emails where some
prominent Apache folks assert that binary packages are not voted on, the
same responder responded with “I think you can”.  None of the 4 other
responders have said “no”.

So, my current plan is this:

At 10:45am in Seattle, unless someone comes up with that good reason not
to, I am going to change the installer’s config file to expose an
additional entry that points to this modified package.  You currently have
to right-click and select “Show Dev Builds” to see it, but I’m going to
move it to the default list. Thus, when you open the DropDown that shows
the list of things you can install, in the list will be “FlexJS 0.0.1”,
“FlexJS 0.0.2”, and additionally “FlexJS 0.0.2 (with JBurg)”.  If folks
want, we could remove the “FlexJS 0.0.2” entry, but my temptation is to
leave it for now.  If you choose "FlexJS 0.0.2” the install will still
fail at the Jburg download (unless SourceForge somehow responds to my
ticket on this issue).  But hopefully folks will then choose “FlexJS 0.0.2
(with Jburg)” and will be successful.

There are no plans to replace the binary package on dist/mirrors as they
work just fine with Ant.  The modified binary package will be installed
from apacheflexbuilds.cloudapp.net.

So, I think the questions are:
1) Is it ok to have the Installer install a different binary package than
the one that was derived from running the build script on the source?
2) Is it ok if that binary package isn’t hosted on dist/mirrors?
3) Is it ok if that binary package includes a modification to LICENSE?
4) Should we leave the current "FlexJS 0.0.2” choice in the list?

IMO, the answer to all four is yes mainly because the binary package isn’t
an act of the foundation.  This modified binary package, just like the
original binary package, is just an act by me to help out community
members to don’t have the setup to work from the source package.  And
while the releasing of the source for the Installer is an official act of
the foundation, the work the Installer does is not, it is just an aid for
our community and it has never installed anything “official”, just


View raw message