On 10/21/14, 6:35 AM, "Harbs" <harbs.li...@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 that. 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 “conveniences”. HTH, -Alex
