incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Sutton <ke...@spoon.as>
Subject Re: [Automation] Could we loose automation for legal or business reasons?
Date Mon, 23 Jan 2012 09:02:39 GMT
Do this mean we are at risk of loosing the automation lib due to business reasons?

---------------------

On 1/23/12 12:14 AM, "Keith Sutton"<keith@spoon.as>  wrote:


> Is there a need to raise this issue collectively with decision makers
> involved in the 'business kinks' to influence this decision?
The issue has been discussed at Adobe, if that's what you mean.

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



On 1/23/2012 12:18 AM, Keith Sutton wrote:
>
> Alex,
>
> You mention 'business kinks' in regards to automation. It would be 
> unfortunate for this project to loose that capability in the framework 
> due to business reasons. The automation library is fairly old (in 
> internet terms) and used by a lot of Flex customers and testing 
> tool/service providers (8-10 of them if not more). With Monocle 
> ramping up as a product it would be sad to see the Apache Flex testing 
> ecosystem being disseminated for it's commercial sake when there is no 
> real competitor to it (even with automation).
>
> Is there a need to raise this issue collectively with decision makers 
> involved in the 'business kinks' to influence this decision?
>
> On 1/22/2012 9:29 PM, Alex Harui wrote:
>>>
>>> On 1/22/12 9:22 AM, "Tink"<flex@tink.ws>  wrote:
>>>
>>>> If automation is missing in our first release, wouldn't that break all
>>>> automation testing that companies have invested in?
>>> Yes, and we would note that in the release notes.  I think we'd have to
>>> lower our goal of the first release to not be something that EVERY 
>>> person
>>> using Adobe Flex can replace.  I certainly wouldn't want to hold up 
>>> releases
>>> of everything else while we work out the legal and business kinks on
>>> automation.
>>>
>>
>>
>


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