Hi, I am one of the third-parties, the "Ardisia Component Library". Sorry about not responding earlier, I just read the thread.
I am thrilled to be included in the Tour De Flex, so first off thanks for including this new feature. I tried building the TourDeFlex with the nightly build from earlier in the thread but I was hit with 100 or so compile errors with path errors and pointers to non-existent components like a Spark RichTextEditor so I must be using an incorrect build. However, earlier in this thread OmPrakash posted screenshots of the problem and I looked at the nightly binary build so I have an idea of the layout issues are. I hate to cause all this trouble . Perhaps my page in the Tour De Flex could just be a label and a link? - Jake On Fri, Nov 7, 2014 at 1:09 PM, Jake Knerr <j...@ardisialabs.com> wrote: > Hi, > > I am one of the third-parties, the "Ardisia Component Library". Sorry > about not responding earlier, I just read the thread. > > I am thrilled to be included in the Tour De Flex, so first off thanks for > including this new feature. I tried building the TourDeFlex with the > nightly build from earlier in the thread but I was hit with 100 or so > compiling errors with path errors and pointers to non-existent components > like a Spark RichTextEditor so I must be using an incorrect build. > However, earlier in this thread OmPrakash posted screenshots of the problem > and I looked at the nightly binary build so I have an idea of the layout > issues are. > > I hate to cause all this trouble . Perhaps my page in the Tour De Flex > could just be a label and a link? > > > > > Say something like what I have now, except go ahead and drop the imagehave > a single page with a list of third party components arranged in a grid > format with a short description of each and a link to the demo. This way, > it could be compiled into the app with minimal effort and > > On Fri, Nov 7, 2014 at 12:00 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 11/7/14, 12:34 AM, "Justin Mclean" <jus...@classsoftware.com> wrote: >> >> >So how do we reach consensus on this in a timely way? If the process >> >doesn't allow a vote and/or people don't vote it's basically dead in the >> >water. I would like to see this released sooner than later and not have >> >releases hanging for weeks, not everyone is full time on this project and >> >increasing the length of the release process stops people from being able >> >to be a release manager. If we had stuck to the official recommend >> >process we probably would of released by now. The previous version of >> >Tour De Flex had two release candidates and was released in 10 days from >> >start of the first RC vote to the final vote result. >> >> Sometimes, releases get stuck on hard issues discovered late in the game. >> It is clear you want to ship as-is, but I think we should make the >> third-party content look good. I was hoping the third parties would have >> offered their thoughts by now. I’m wondering if they’ve at least tried >> the nightly build at [1] and saw how their content appears, because that’s >> how it will behave when published to flex.a.o. >> >> Also, have you investigated the Squiggly issue brought up yesterday [2]? >> I also get the exception. It could just be a bug in the CI server setup. >> >> Both Squiggly and Third Party examples are highlighted in the >> RELEASE_NOTES and both are not fully operational. >> >> > >> >It's also curious as to why you only decide to bring this content load >> >strategy up now and state it as a blocker for releasing, rather than when >> >we we were discussing adding 3rd party support for it several months ago. >> >> It never crossed my mind until I saw the issue brought up on this thread. >> If we had established Jenkins builds sooner, then maybe we would have >> found it sooner, because it was only when I saw it that I realized what >> was going on, and only after thinking about it more did it occur to me >> that we really should get Marshall Plan separation from the third parties. >> If we can’t engage them on this sizing/position issue, we probably don’t >> want to depend on them staying in sync on SDK versions going forward. >> >> -Alex >> >> [1] http://s.apache.org/sC4 >> [2] http://s.apache.org/hqe >> >> > > > -- > Jake Knerr - Flex Developer > Ardisia Labs > www.ardisialabs.com > -- Jake Knerr - Flex Developer Ardisia Labs www.ardisialabs.com