This is why Erik suggests a legal-discuss@flex.a.o ML: so you and I can argue
this without polluting the dev list with noise.
From: Justin Mclean [jus...@classsoftware.com]
Sent: Sunday, June 29, 2014 11:08 PM
To: dev@flex.apache.org
Subject: Re: [DISCUSS]
Hi,
>> Check out this link. I think it disagrees.
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201405.mbox/%3cCAAS6=7iGt0xW4oBe0sSXC7RzGgDP=kubhgkojzuezbbirq2...@mail.gmail.com%3e
A little further down it also says that release candidates are "packages are
intended for develop
On Sun, Jun 29, 2014 at 10:26 PM, Alex Harui wrote:
> Again, this script does not decide on the correctness of the
> LICENSE/NOTICE, so every time some one or the same person runs it, there is
> the same chance they will catch an error as if they had typed the
> command-line commands themselves.
Hi,
> Check out this link. I think it disagrees.
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201405.mbox/%3cCAAS6=7iGt0xW4oBe0sSXC7RzGgDP=kubhgkojzuezbbirq2...@mail.gmail.com%3e
This is basically from [1] and that it is referring to links from our web site,
I think in this cas
Back to technical topics:
I think I am going to go with adding another attribute to config-4.0.xml and
have the 4.13.0 and FlexJS 0.0.2 release use them. This will require a new
installer RC as well since installer has to pass that new attribute to the ant
script. The attribute will be called
From: Erik de Bruin [e...@ixsoftware.nl]
Sent: Sunday, June 29, 2014 10:57 AM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
>Also, I suggest that we keep to the actual voting rules: when 72 hrs pass,
>t
From: Justin Mclean [jus...@classsoftware.com]
Sent: Sunday, June 29, 2014 5:30 PM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
Hi,
>>> 2) A slower release candidate cycle would help, IMO you'll get mo
Again, this script does not decide on the correctness of the LICENSE/NOTICE, so
every time some one or the same person runs it, there is the same chance they
will catch an error as if they had typed the command-line commands themselves.
The script does not vote for you, it is only intended to
Thanks for catching that. I think I have learned that we can link to the Adobe
version.
I will make the adjustments.
-Alex
From: Justin Mclean [jus...@classsoftware.com]
Sent: Sunday, June 29, 2014 6:25 PM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] D
OK, will take a look
From: Justin Mclean [jus...@classsoftware.com]
Sent: Sunday, June 29, 2014 8:50 PM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] Discuss Apache Flex SDK 4.13.0 RC2
Hi,
Also we do have a potential issue, while it not on the core list o
Hi,
+0 binding for now. While the RSL issue is not blocking as such, it will most
likely cause issues.
On OSX I checked:
- Signatures good
- NOTICE and LICENSE good
- README/RELEASE_NOTE fine
- source release matches git tag (except flex config file)
- flex description looks good
- flex framewor
Hi,
Also we do have a potential issue, while it not on the core list of things to
check it has the potential to cause issues with RSLs.
The flex config file doesn't match what's is in version control - it has the
correct build number rather than the ${build.number} tokens, when compiling the
S
Hi,
A bit belated but Flex is now more than 10 years old. Version 1 was release by
Macromedia way back on March 29 2004 [1].
Justin
1.
http://web.archive.org/web/20040405040959/http://www.macromedia.com/macromedia/proom/pr/2004/flex_available.html
Hi,
They all seem to be popping out of the woodwork - sigh.
Just found this:
./apache-flex-sdk-4.13.0-src/asdoc/templates/images/AirIcon12x12.gif
It's used to indicate what API elements are supported only in AIR - something
very useful in the documentation.
Persons sensitive to legal matters p
HI,
> The approval scripts attempt to get you to vote with less hassle.
Again to make clear a script is in no way a replacement for voting. Don't get
me wrong it's very useful as a basic check and hopefully that will mean people
will vote more. But put it this way, running the script 1000 tim
Hi,
>> 2) A slower release candidate cycle would help, IMO you'll get more
>> reviews, more testing and less release candidates overall.
> Fewer releases per year doesn't sound helpful to the community.
release candidate != release I'm talking about how often RCs are produced in a
single release
>
> >OK, that's nice and all, but let's get into specifics. What do you suggest
> >we do to simplify and speed up the release process of the separate
> >projects?
> The approval scripts attempt to get you to vote with less hassle. There
> could be more improvements in the scripts to show diffs in
I've rebooted the VM again, let's see if the pattern does indeed hold true.
EdB
On Sun, Jun 29, 2014 at 6:22 PM, wrote:
> flex-sdk_mustella - Build # 967 - Still Failing:
>
> http://flex-mustella.cloudapp.net/job/flex-sdk_mustella/967/
>
> Changes for Build #965
>
> Changes for Build #966
>
On 6/29/14 9:10 AM, "Erik de Bruin" wrote:
>>
>> something that's missing. We are not allowed to use nightly builds as a
>> rapid release mechanism.
>>
>
>That is silly. I think we should beat the lawyers at their own game and
>just refrain from calling the nightlies "releases" and proceed to
>
> something that's missing. We are not allowed to use nightly builds as a
> rapid release mechanism.
>
That is silly. I think we should beat the lawyers at their own game and
just refrain from calling the nightlies "releases" and proceed to make them
the way early adopters meet FlexJS.
The re
I didn't look back too far, but it appears there is a hudson class in the
first failure and after that we get Git failures?
For the hudson failure (which is Jenkins, right?) I note that the failure
was on one of the last batches of tests that are in a mustella run. Does
jenkins try to timeout aft
On 6/29/14 8:27 AM, "Erik de Bruin" wrote:
>>
>> the community. We need to make this process simpler and faster. We're
>> going to have six releases once we start shipping BlazeDS.
>>
>
>What are the pros and cons of having one monolithic "Apache Flex All"
>release 4 times a year. All subproj
>
> the community. We need to make this process simpler and faster. We're
> going to have six releases once we start shipping BlazeDS.
>
What are the pros and cons of having one monolithic "Apache Flex All"
release 4 times a year. All subprojects depend on one another anyway, why
not aim for inc
On 6/29/14 7:29 AM, "Justin Mclean" wrote:
>Hi,
>
>> And then, if your answer is yes, as a release manager, I would request a
>> couple of things.
>
>And in return I also like to request a few things:
>
>1) The RM shouldn't assume everyone can do this as a full time job
What gave you that impre
OK, this is now happening every cycle: I reboot the VM. The first Mustella
'main' runs fine and passes. The next run however fails with a complicated
seemingly Java related issue. Every next run fails as above, until I
reboot. Rinse, repeat. I'm at a loss what is going on...
EdB
On Sun, Jun 29
Hi,
> And then, if your answer is yes, as a release manager, I would request a
> couple of things.
And in return I also like to request a few things:
1) The RM shouldn't assume everyone can do this as a full time job, reviewing
release properly is difficult and sometime the issues are not easy
Ok ... so then I would vote for this to be downloaded too ... I would really
like to make the Mavenizer also create runtime artifacts with the Flashplayer
:-)
Chris
-Ursprüngliche Nachricht-
Von: Justin Mclean [mailto:jus...@classsoftware.com]
Gesendet: Sonntag, 29. Juni 2014 11:22
An
I'm not saying the update isn't important, I'm saying the differences to
the APIs and even player internals (if any) are too small to particularly
matter from a Flex dev's point of view.
EdB
On Sun, Jun 29, 2014 at 11:01 AM, Justin Mclean
wrote:
> Hi,
>
> > The differences between 14 and 14b
Today it runs in a continuing cycle, day in day out - unless something
crashes it, which is fairly often... A full run (main, AIR and mobile
tests) takes about 14 hours to complete. Each full run is against one
FP/AIR version pair. Currently I maintain 4 such pairs: 11.1/3.7, 11.7/3.7,
13/4 and 14/
Hi,
> So is there a reason for us not downloading the stand-alone flash player?
> Would be really cool if we did ;-)
No reason as far as I know (as long as your not distributing it as they would
need a license). I'd say it's mostly due to teh fact that it's usually
installed and you don't need
Hi,
currently the installer downloads the Air SDK (containing the libraries and the
runtime) but for Flash we only download the playerglobal.
I am currently working on mavenizing the runtime artifacts so Flexmojos can
pick them up via maven and usem without having to add a flashplayer executable
Hi,
> The differences between 14 and 14b are probably too small to matter.
I believe it include updated OpenSSL libs that are not effected by heart bleed
- that's probably important even if it's only perception. I think I saw some
Android apps were being rejected because of using the wrong vers
OK ... so now the next question ... how often and how long does the Mustella
suite need to run?
Chris
-Ursprüngliche Nachricht-
Von: Erik de Bruin [mailto:e...@ixsoftware.nl]
Gesendet: Samstag, 28. Juni 2014 19:02
An: dev@flex.apache.org
Betreff: Re: Dedicated Windows Agent
The Azure V
On Sun, Jun 29, 2014 at 12:01 AM, Erik de Bruin wrote:
> The differences between 14 and 14b are probably too small to matter. I
> wouldn't worry too much and don't offer beta installs if they are on the
> same version. Just re-activate the beta installs when they start the 15
> cycle, and stop it
The differences between 14 and 14b are probably too small to matter. I
wouldn't worry too much and don't offer beta installs if they are on the
same version. Just re-activate the beta installs when they start the 15
cycle, and stop it again once there is a 15 release.
EdB
On Sun, Jun 29, 2014
35 matches
Mail list logo
