I have published flexjs 0.7.0 on the npm repository. You can install it by running:
npm install flexjs -g Before publishing, I confirmed that the npm flexjs package does indeed download from the mirrors: ================== *Downloading Apache FlexJS from mirror: http://mirror.symnds.com/software/Apache/flex/flexjs/0.7.0/binaries/apache-flex-flexjs-0.7.0-bin.zip <http://mirror.symnds.com/software/Apache/flex/flexjs/0.7.0/binaries/apache-flex-flexjs-0.7.0-bin.zip>* Apache FlexJS download complete Extracting Apache FlexJS Apache FlexJS extraction complete Downloading Apache Flex Falcon Compiler *Downloading Apache Flex Falcon Compiler from mirror: http://apache.mirrors.ionfish.org/flex/falcon/0.7.0/binaries/apache-flex-falconjx-0.7.0-bin.zip <http://apache.mirrors.ionfish.org/flex/falcon/0.7.0/binaries/apache-flex-falconjx-0.7.0-bin.zip>* Apache Flex Falcon Compiler download complete Extracting Apache Flex Falcon Compiler ================== Thanks, Om On Wed, Sep 14, 2016 at 11:55 PM, Harbs <harbs.li...@gmail.com> wrote: > +1. > > Let’s keep things positive and keep things rolling. > > Like we’ve discussed in the past, let’s try not to read too much intent > into emails. Email is a bad medium for conveying intent. I didn’t read bad > intent from anyone here. > > Thank you Alex for getting this release out, and thank you Justin for > helping us find IP issues. :-) > > I didn’t see anything which should delay the release announcement. We can > look into whether there’s a better way of pushing things to npm before our > next release. Justin, if you have suggestions on that front, I think we’re > all happy to hear. > > Thanks, > Harbs > > On Sep 15, 2016, at 7:15 AM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 9/14/16, 4:27 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > > > >> > >> Perhaps the question we should be asking is why are other PMC members > are > >> not finding these issues earlier as well? > > > > Well, I can only speak for myself, but I have learned over the years > that, > > while we can't say "Community over Policy" since policy is important, > > community is still more important than trying to nail every last detail > of > > the licensing. For sure, early on, I thought we had to nail every last > > detail, but senior Apache members have advised us that we can use "trust" > > and "intent" in approving releases. So I look at harder at what we are > > saying is our source, take a trusting, high-level look at what > > third-parties say we can do and go from there. Because if we do make a > > mistake in the details, it isn't the end of the world, we can fix it in > > the next release, and the best way to guarantee there will be a next > > release is to make sure the release process is quick and more like a > > celebration of work completed than a grind through fine print. If we can > > do that, we might find more folks will want to be release managers, > > releases will take less energy so they can happen more often, and the > > community will grow as a result. IOW, I am always looking for reasons to > > ship, not reasons not too, especially late in the game. > > > > Now also for sure, there is nobody in the entire foundation (not just > this > > project) who is better than you at finding licensing issues, and if you > > want to help other PMC members find more of these issues, it would be > > great if you could share your processes with us and the ASF in general. > > > > Another way to look at it is that if the ASF truly cared about nailing > > every last detail, the policy would be that you could use a licensing > > issue to veto a release. It puzzled me for a while that it wasn't that > > way, but I've come to think that the real goal is to build communities > and > > share source code without involving lawyers and tons of time. I think > the > > ASF realizes that these communities are almost all non-lawyers trying to > > make the world better through shared code and they may (as we know) have > > not nailed their documentation down to the last detail. And thus, we > > don't have to look too hard, especially at third-party bundles. If > > something comes up, we can deal with it in the next release. We can > trust > > that third-parties are not trying to lay some trap or sneak in a trojan > > horse. > > > > I personally don't enjoy grinding through the details of license and > > notice stuff. My sense is that there are several others in our community > > who feel the same way and wonder if others have left us and what other > > code we could have done, and contributors we could have attracted if we > > didn't spend as much time grinding on it. As long as the right > > attribution is there at a high-level, I think we are good to go and > > volunteers can improve it, just like we improve our code, over time. > > > > Now let's push the NPM bits, get the announcement out, and get going on > > the building the future of Flex. > > > > Thanks, > > -Alex > > > >
