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:
Apache FlexJS download complete
Extracting Apache FlexJS
Apache FlexJS extraction complete
Downloading Apache Flex Falcon Compiler
*Downloading Apache Flex Falcon Compiler from mirror:
Apache Flex Falcon Compiler download complete
Extracting Apache Flex Falcon Compiler


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
> >

Reply via email to