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 <flexcapaci...@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 <aha...@adobe.com> wrote: > >> >> >> On 11/5/15, 3:56 AM, "Harbs" <harbs.li...@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 <aha...@adobe.com> wrote: >> > >> >> >> >> >> >> On 10/30/15, 3:19 PM, "Justin Mclean" <jus...@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 >> > >> >> >
