On 6/20/12 8:59 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:

> Hi,
> 
>> It won't be in the distribution (since it wasn't in Adobe releases, and I'm
>> not really sure it makes sense to put that
>> much stuff in a distribution).
> I would vote for it's inclusion into the SDK - not having some way of testing
> the SDK was probably the number one complaint and having it (IMO) would make
> people more likely to make improvements and quality of the SDK. For parity
> release it's probably not needed.
It will go in the mustella folder in the trunk, but I still don't think we
should add it to the source distributions.  Those who wish to use mustella
to test can certainly download it from SVN and use it.  I don't think
everybody getting the release needs to run mustella and those who do would
probably find it faster to refresh SVN.
> 
>> Carol and/or I will run the release against our private working copies of it.
> No offence intended, but wouldn't it be better if it was independently
> verified? 
For sure.  We expect all of you to run as many non-mustella tests as you can
against the release candidates and then vote.  IMO, we should not hold up
the parity release to wait for Mustella to be donated.  I think we're almost
ready to have everyone pound on a release candidate, but I think the
approval process for Mustella could take until mid-July.

> Even if Mustella can't be included in the parity release could it be
> put up somewhere so other people can have access to it to verify the parity
> release? 
No, we can't make it public without essentially going through the process we
are going through right now.
> Even if the tests are not passing 100% is would be useful to have
> access to it soon than later.
Yes, we will be donating it with broken tests.  We are simply finishing up
an legal scrub that was just awful and fixing enough tests to rid the
baseline media of unallowed media.  Then we have to get legal to review our
work and the VP to sign.
> 
>> It would be interesting to know whether 3.x should be higher priority than
>> Additional Spark Components.
> I's guess that spark components should be first and 3.x higher on the list as
> I do know of projects who have not migrated to 4.x yet. (Although as more time
> goes on 3.x probably becomes less important.)
> 
> Thanks,
> Justin

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Reply via email to