flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: [DISCUSS] Release Apache FlexJS 0.5.0
Date Thu, 05 Nov 2015 23:47:53 GMT
Ok, the reason why I was so confused is because it's "ApproveFlexJS" build.
:P I thought it was the install and run script. Is there a another ant
build file?

On Thu, Nov 5, 2015 at 3:21 PM, jude <flexcapacitor@gmail.com> wrote:

> Alex,
> I'm going to go ahead and put together an app so that you can install
> FlexJS with one click and compile. I want it to be as simple as possible
> for anyone (new web developers). I've downloaded the build script and
> looked over it but there is some code in it for voting and release. I'm
> sure you will be repeating yourself again but here's my requirements:
>
> • button to validate FlexJS requirements (paths, etc)
> • button to set paths for the user
> • one button to download FlexJS
> • another button to run FlexJS on a project app (without an IDE)
>
> Are there targets to do each of these (or where should I start)? Since
> it's an AIR app I want to run each target independently. BTW I'm bundling
> ant with the app so that the user doesn't have to install anything extra.
> If someone has FB or IntelliJ installed does the install directory need to
> change? I'll put the project on github or post it to the group as soon as
> it's usable.
>
>
> On Thu, Nov 5, 2015 at 6:32 AM, Alex Harui <aharui@adobe.com> wrote:
>
>>
>>
>> On 11/5/15, 3:56 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>
>> >I’m a bit confused about the release process.
>> >
>> >I thought we were creating release branches in git for each release to
>> >“freeze” the code, so we do not have a wildly moving target. It does not
>> >seem like that’s happening, so I’m not sure if I just misunderstood.
>>
>> You understand correctly.  I’m cheating right now because it is just more
>> work to set up release branches, and there isn’t a lot of non-critical
>> work going on the develop branch.  Peter and I are working on the back
>> port from JS to AS in a separate branch.  Only important fixes are being
>> pushed to develop.  If we had more folks contributing more often, then I
>> would have used a release branch.
>>
>> Even release branches have historically moved because folks don’t start
>> testing until late in the game and find important bugs.
>>
>> -Alex
>>
>> >
>> >Harbs
>> >
>> >On Nov 3, 2015, at 12:04 AM, Alex Harui <aharui@adobe.com> wrote:
>> >
>> >>
>> >>
>> >> On 10/30/15, 3:19 PM, "Justin Mclean" <justin@classsoftware.com>
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>> Hmm, I was hoping more PMC folks would respond.  Remember that,
>> >>>> according
>> >>>> to the release process, the PMC folks planning to vote are supposed
>> to
>> >>>> be
>> >>>> running tests now. In theory, the only new test to be run  after
we
>> >>>> start
>> >>>> the vote is whether the PGP signature is valid.
>> >>>
>> >>> We’re continually trying to test a moving target which involves a
>> >>>greater
>> >>> time commitment that I currently have available. You’ve never quite
>> >>>sure
>> >>> if the version you testing is going to be the version in the release
>> >>> candidate and unless you very carefully follow all of the commits it’s
>> >>> not obvious what needs to be retested at two different time intervals.
>> >>
>> >> Hmm, pleading is working so maybe I’ll try guilt-tripping.
>> >>
>> >> Yes, the nightly builds are a moving target.  IMO, we all want to grow
>> >>the
>> >> community by attracting customers and hopefully convert a few to be
>> >> committers and the only way I know to do it is to keep making the code
>> >> better and releasing the best release we can in the most efficient
>> >>manner.
>> >> IMO, freezing a branch and not allowing important bug fixes that might
>> >> make a difference in whether someone becomes more active in our
>> >>community
>> >> doesn’t make sense.  Taking the time to build out an RC and post it and
>> >> start a vote thread in order to finally get some testing isn’t very
>> >> efficient either.
>> >>
>> >> Historically, when we produced an RC and immediately started a release
>> >> vote, bugs would be found and we’d cancel the RC and roll out another
>> >>one.
>> >> The goal of the release process we voted in, IMO, was to reduce this
>> >> overhead of posting RCs, opening and closing vote threads, etc. so we
>> >>can
>> >> more efficiently achieve the goal of serving our customers and
>> >>attracting
>> >> some of them to becoming committers so we can have more people find
>> bugs
>> >> sooner by working with the develop branch.
>> >>
>> >> Recently, I’ve spent several days on improving build and approval
>> >>scripts
>> >> so testing what is in development takes less time.  In theory, you can
>> >>now
>> >> start up the approval script which will pull down the bits, answer a
>> few
>> >> questions, then go do something else for 5 to 25 minutes and then come
>> >> back and poke at it.  I would have rather spent that time on features
>> >>for
>> >> our customers, but I gambled that this would help us get the release
>> out
>> >> sooner.  I’m not sure that paid off.
>> >>
>> >>
>> >> I don’t have any other ideas on how to make it easier for those of you
>> >>who
>> >> contribute in your spare time to stay up on the commits and bugs.  It
>> >> should be ok to take any nightly build and run it through your tests
>> and
>> >> report your findings.  Ideally, you would be up to date on the commits
>> >>and
>> >> bugs and other discussions to know whether what you find is a duplicate
>> >>or
>> >> not, but at this point, I don’t care if you report a duplicate.  At
>> >>least
>> >> that means you verified a bunch of other code paths worked for you.  I
>> >> don’t know how other Apache projects with really active code bases do
>> >>it.
>> >>
>> >> It is certainly fine to be too busy to vote on a release.  I was hoping
>> >>to
>> >> get more folks to poke at the bits before starting a vote because it
>> >>will
>> >> be a waste of community energy to start a vote and then have a bunch of
>> >> PMC voters jump in and start reporting important bugs.  But I think the
>> >> community has waited too long already, so I am going to start a vote
>> >>soon,
>> >> and Peter and I will vote and maybe Josh and/or Harbs and we’ll be good
>> >>to
>> >> go.  Hopefully any others jumping in late won’t find release blockers
>> >>and
>> >> we’ll just make another release later.
>> >>
>> >>
>> >> -Alex
>> >
>>
>>
>

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