flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [DISCUSSION] TourDeFlex 1.2 RC 0
Date Fri, 07 Nov 2014 19:00:52 GMT

On 11/7/14, 12:34 AM, "Justin Mclean" <justin@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.


[1] http://s.apache.org/sC4
[2] http://s.apache.org/hqe

View raw message