Re: [LAST CALL] one week till the release branch is cut
Hi, Currently these issues are being worked on: - stabilizing TLF - use Apache Flex BlazeDS jar(s) instead of Adobe version And several JIRA issues are assigned and I presume under development. Is someone else working on anything else that they want considered to be part of the next release? Thanks, EdB On Thu, Dec 4, 2014 at 11:41 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, A friendly reminder that we're nearing another milestone towards the 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 09:00), to be precise, I'll cut the release branch. This marks the last opportunity for any features or 'normal' bug fixes to be committed to the repo and be included in the release. If you want to contribute to this release, please consider taking on one of these issues [1], or start checking the documentation and the state of the SDK through the nightlies or from the source in the 'develop' branch. Thank you! EdB 1: https://issues.apache.org/jira/browse/FLEX-34562 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: WindowApplication.as edit / ApplicationDPI scaling bug ?
I think your right in identifying a work around, fixing the sdk is proving
harder than I hoped and I'm lacking the familiarity to isolate the issue. Plus
it could be a while before I got anything through the release process.
I've had a play around and I think I've come up with a variation/extension to
your solution that does the job for me.
I still set the applicationDPI / runtimeDPI and then set the application
contentGroup size to the application system manager screen dimensions. The math
is basically as you've described except I'm using the application contentGroup
instead of putting in my own group and I'm letting the system manager /
internals carry out the scaling.
--- extract --
// Changes the initial size of the application so it
appears physically the correct size according to the device DPI.
private function applicationCompleteHandler():void
{
this.width /= this.applicationDPI /
this.runtimeDPI;
this.height /= this.applicationDPI /
this.runtimeDPI;
}
// Sets the application content width and hieght to the
application's system managers calculated screen size.
protected function resizeHandler(event:ResizeEvent):void
{
if (this.systemManager)
if (this.systemManager.screen)
{
this.contentGroup.width =
this.systemManager.screen.width;
this.contentGroup.height =
this.systemManager.screen.height;
}
}
--- extract end ---
I think this will do the job or something similar.
Thanks for the help Lee, I'll post the work around on JIRA.
All the best
Jason :)
-Original Message-
From: Subscriptions [mailto:subscripti...@leeburrows.com]
Sent: 05 December 2014 17:47
To: dev@flex.apache.org
Subject: Re: WindowApplication.as edit / ApplicationDPI scaling bug ?
This code works for me (by scaling a group). I leave it you to determine a
suitable calculation for newScale value. Custom runtimeDPIprovider not needed
as default returns 160 (which is fine)
?xml version=1.0 encoding=utf-8?
s:WindowedApplication xmlns:fx=http://ns.adobe.com/mxml/2009;
xmlns:s=library://ns.adobe.com/flex/spark
xmlns:mx=library://ns.adobe.com/flex/mx
applicationDPI=160
creationComplete=init()
fx:Script
![CDATA[
import mx.events.FlexEvent;
protected function init():void
{
var newScale:Number = 2;
grp.scaleX = newScale;
grp.scaleY = newScale;
}
]]
/fx:Script
s:Group id=grp
left=0 right=0 top=0 bottom=0
s:Label id=LeftMarker left=0 verticalCenter=0
text=lt;--- LEFT fontSize=24/
s:Label id=MiddleMarker horizontalCenter=0
verticalCenter=0 text=gt; gt; gt; MIDDLE lt; lt; lt;
fontSize=24/
s:Label id=RightMarker right=0 verticalCenter=0
text=RIGHT ---gt; fontSize=24/
/s:Group
/s:WindowedApplication
Lee Burrows
ActionScripter
On 05/12/2014 17:37, Subscriptions wrote:
I havent tested it but a possible workaround would be to avoid flex
scaling completely and write your own... either set stage.scaleX/Y as
appropriate (or maybe you will need to put all your content inside a
group and scale the group).
Having said that, the more i think about it, i'm not sure scaling a
desktop app is ideal (even if window cant be resized by user) - but
i'm guessing your app is too far into development to change that?
Lee Burrows
ActionScripter
On 05/12/2014 16:54, Jason Moore wrote:
Hi All,
I submitted a bug to the Jira system around how the application
scaling using applicationDPI for desktop Air Apps seems to be broken.
I've included screenshots, example code etc.. so I won't go into
detail here, if you're interested and can help please do have a look.
https://issues.apache.org/jira/browse/FLEX-34653
Anyway, I've checked out the source... and have been playing around
but I can't seem to get any changes to the WindowedApplication.as
(\frameworks\projects\airspark\src\spark\components) to do anything.
Trace statements don't work, I've even put in deliberate errors... to
no effect. Changes and trace statements in other parts of the
framework such as systemManager.as appear so I know I'm compiling and
using my edited source.
Is there something special about the WindowedApplication.as ... is it
overridden somewhere in the build?
Any help appreciated.
Jason
Re: [RP] When to release?
On 07/12/14 07:29, Erik de Bruin wrote: Is there enough support for releasing this subproject at this point in time? I think this is always a good thing to ask :-) I'm not aware of anything like a roadmap that says we'll release version X of Y on date Z, so we don't have that to kinda push us along. I don't see any need to have them either. So our releases are either bug fixes (one bug that's big enough, or it's been so long, there are many fixes, we should) or features (we finished months of work to get Z done). Tom
Re: Carried RC Votes
Hi, I agree that the key thing here is that your releases have to be approved according to [0], from the ASF's point of view that's all. This means that before you publish the release artifacts the apache.org archive of this list needs to contain a documented trace that shows that you indeed got at least three +1 votes from PMC members, and less -1 than +1 votes on the artifacts that you released. It is indeed the responsibility of the release manager to ensure that this trace exists before releasing the artifacts, and to document this here in a [VOTE][RESULT] message that closes the release vote. This whole business of RCs makes that much more complicated than it should be IMO...in all the Apache projects where I've been active, releases are just discarded if they fail to get majority approval, or when the release managers feels that the raised objections warrant ditching the release. If a release fails to get majority approval, the release process starts over: create new artifacts, a new VOTE thread, collect those 3 +1s, tally the vote and you're good. Git or svn diffs will show how much changed between that new release and the one that failed, so re-checking the new release is easy: check the diffs between the new and old Git or svn tags and verify that the release tarball or other archive matches the content of those svn tags. Cast your +1 and you're done. So once again as per [1] my recommendation would be to not do release candidates anymore, consider each new set of releasable artifact as a new release, drop the releases who don't pass and publish those which do. Letting each (potential) release live in isolation should make your life easier. Like, dropping this discussion ;-) -Bertrand [0] http://www.apache.org/dev/release.html#approving-a-release [1] http://markmail.org/message/4ahntni6kzfnwjzw
[TTH] it's not that complicated
One last thought after reviewing your recent community difficulties: my general feeling that this PMC is making things more complicated than it should, based on a vague belief that the Apache Software Foundation has tons of complex requirements and processes that need to be followed. That's not the case - there are some rules and requirements, but AFAICS much fewer than the general perception here seems to be. The what makes Apache projects different? post [1] that I wrote a while ago tries to capture the key differences between Apache projects and just sharing a code repository. There's really not more to it than that - keeping things simple should help. -Bertrand [1] https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different
Release guides on Wiki
Hi, Since it turns out to be not so complicated, I have made some minor adjustments to the release documentation ([1] and [2]), and moved the 'A guide to the Apache Flex release process' article (previously known as the 'less-RC' proposal) to a more accessible location in the wiki. The discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest we use the usual wiki workflow to correct any mistakes. Now, do we vote to codify this? I suggest we don't. If anyone thinks substantive changes are needed - that have not yet been discussed - they are free to turn to the dev@ list, and, if no clear majority for handling it one way or another is clear, start a vote on the proposed changes. EdB 1: https://cwiki.apache.org/confluence/x/2oH0Ag 2: https://cwiki.apache.org/confluence/x/OQDFAQ -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: [RP] When to release?
Should we just leave a one month break, in-between releases and start working on the next one after that? Meaning there could be an SDK release every 2 months or up to 6 times a year. Releases would show minor revisions unless there is a significant addition to the change list. -Start release cycle (takes roughly a month) -After release is complete 1 month to gather more changes. -Start next release cycle. -Mark
Re: [CONF] Apache Flex A guide to the Apache Flex release process
Hi, This message wasn't delivered as I suspect you intended. In that it wasn't sent to dev? OK resending to dev. -1 (and that's a veto). Please revert these changes and open to discussion first. Why? There's been no agreement on After polling the dev@ list to see if there is enough interest in creating a release and that's not Apache policy. Justin
Re: [CONF] Apache Flex A guide to the Apache Flex release process
On 08/12/14 13:24, Justin Mclean wrote: that's not Apache policy. What did Bertrand *just say* in the post with subject [TTH] it's not that complicated ? Stuff like this *doesn't have an Apache policy*. It's also very unclear who you were responding too and about what. Probably because you are replying to a bounce message or something, I think ? Assuming you mean some minor point that you feel hasn't been discussed enough in the new release process we're adopting, why does what Erik suggested (my emphasis): discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest *we use the usual wiki workflow to correct any mistakes* not apply ? You could just have noted this one sentence needed clearing up there and saved some time here for everyone else ? Please consider reviewing your vote, Tom
Re: [CONF] Apache Flex A guide to the Apache Flex release process
Justin, Please see [1]. I don't accept the veto, as I don't see how changing a wiki text is against Apache policy. I've reworded the sentence to make it's intention clearer. It's a practical one statement, meant to help an RM avoid starting a release that nobody else cares enough about to help with. At the same time, it is meant to help the community - and especially the PMC - by not being 'forced' to deal with minor releases they may not have time to properly check out and vote on. EdB 1: http://markmail.org/message/qsv4bwxxlvaaschq On Mon, Dec 8, 2014 at 2:24 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, This message wasn't delivered as I suspect you intended. In that it wasn't sent to dev? OK resending to dev. -1 (and that's a veto). Please revert these changes and open to discussion first. Why? There's been no agreement on After polling the dev@ list to see if there is enough interest in creating a release and that's not Apache policy. Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [CONF] Apache Flex A guide to the Apache Flex release process
Sorry Tom, we seem to have crossed our beams. Let's hope we didn't accidentally destroy the universe and somehow are not (yet) aware of it ;-) Thanks, EdB On Mon, Dec 8, 2014 at 2:40 PM, Tom Chiverton t...@extravision.com wrote: On 08/12/14 13:24, Justin Mclean wrote: that's not Apache policy. What did Bertrand *just say* in the post with subject [TTH] it's not that complicated ? Stuff like this *doesn't have an Apache policy*. It's also very unclear who you were responding too and about what. Probably because you are replying to a bounce message or something, I think ? Assuming you mean some minor point that you feel hasn't been discussed enough in the new release process we're adopting, why does what Erik suggested (my emphasis): discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest *we use the usual wiki workflow to correct any mistakes* not apply ? You could just have noted this one sentence needed clearing up there and saved some time here for everyone else ? Please consider reviewing your vote, Tom -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [CONF] Apache Flex A guide to the Apache Flex release process
Honestly guys this is getting ridiculous, it's been days now. I'm actually considering making a world war 2 style documentary about this. Battle For The Button: Release. Synopsis: Join us as we recount the riveting tale of one mans battle against an army of contributors. He single-handedly repelled the efforts and input of absolutely everyone to maintain control the publish release button. What do think? For the sequel, it's still up in the air, but I'm playing with a title: Apache Flex - Dead At Version 4.13. Or maybe Apache Flex 4.13 - Over 9000 Commits Behind Master Hopefully this is over before I hit the spam button. On Mon, Dec 8, 2014 at 9:40 AM, Erik de Bruin e...@ixsoftware.nl wrote: Sorry Tom, we seem to have crossed our beams. Let's hope we didn't accidentally destroy the universe and somehow are not (yet) aware of it ;-) Thanks, EdB On Mon, Dec 8, 2014 at 2:40 PM, Tom Chiverton t...@extravision.com wrote: On 08/12/14 13:24, Justin Mclean wrote: that's not Apache policy. What did Bertrand *just say* in the post with subject [TTH] it's not that complicated ? Stuff like this *doesn't have an Apache policy*. It's also very unclear who you were responding too and about what. Probably because you are replying to a bounce message or something, I think ? Assuming you mean some minor point that you feel hasn't been discussed enough in the new release process we're adopting, why does what Erik suggested (my emphasis): discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest *we use the usual wiki workflow to correct any mistakes* not apply ? You could just have noted this one sentence needed clearing up there and saved some time here for everyone else ? Please consider reviewing your vote, Tom -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Jesse Nicholson
Re: [RP] When to release?
Sorry, kept forgetting to reply. I would prefer we not create a schedule. When to release should factor in momentum, importance to the community, even marketing opportunities like conferences. IMO, if a someone wants to take the time and effort to be an RM for a release, and can make the case that the new things in the release are going to be worth the effort to release it, and it won’t take away from momentum of someone else trying to release one of our other packages, then, until my work situation changes, I will always find time to review it (although I may not get to it right away). And if I don’t see enough other folks step up to review that release, until Peter’s work situation changes, I will ask Peter to review it as well. So, at least for now, anyone who wants to be an RM can be pretty sure there will be 3 voters. -Alex On 12/8/14, 5:08 AM, Kessler CTR Mark J mark.kessler@usmc.mil wrote: Should we just leave a one month break, in-between releases and start working on the next one after that? Meaning there could be an SDK release every 2 months or up to 6 times a year. Releases would show minor revisions unless there is a significant addition to the change list. -Start release cycle (takes roughly a month) -After release is complete 1 month to gather more changes. -Start next release cycle. -Mark
Re: Release guides on Wiki
Thanks for doing this. I don't think there is a need for a vote since there is a general consensus around the contents of the wiki. Obviously, we can tweak the wiki as needed when some new situation arises which has not already been addressed. Thanks, Om On Dec 8, 2014 5:06 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Since it turns out to be not so complicated, I have made some minor adjustments to the release documentation ([1] and [2]), and moved the 'A guide to the Apache Flex release process' article (previously known as the 'less-RC' proposal) to a more accessible location in the wiki. The discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest we use the usual wiki workflow to correct any mistakes. Now, do we vote to codify this? I suggest we don't. If anyone thinks substantive changes are needed - that have not yet been discussed - they are free to turn to the dev@ list, and, if no clear majority for handling it one way or another is clear, start a vote on the proposed changes. EdB 1: https://cwiki.apache.org/confluence/x/2oH0Ag 2: https://cwiki.apache.org/confluence/x/OQDFAQ -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Carried RC Votes
Hi Bertrand, Again, thanks for taking the time to follow all of these lengthy threads. I just want to makes sure I understand one point (in-line below): On 12/8/14, 3:02 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Git or svn diffs will show how much changed between that new release and the one that failed, so re-checking the new release is easy: check the diffs between the new and old Git or svn tags and verify that the release tarball or other archive matches the content of those svn tags. Cast your +1 and you're done. So once again as per [1] my recommendation would be to not do release candidates anymore, consider each new set of releasable artifact as a new release, drop the releases who don't pass and publish those which do. Letting each (potential) release live in isolation should make your life easier. Like, dropping this discussion ;-) My takeaway is that we can vote +1 without checking everything each time, and that, by engaging folks to check most things before actually calling for a vote there will be fewer failed votes, but we already saw that, when we thought we’d found everything important and did call for a vote, that a critical problem was found. Even though we don’t have to check everything before voting +1 on the next RC, even the minimal steps you mention take time. Are you opposed to having folks who voted +1 on the prior RC offer carryover votes for those next RCs? Thanks, -Alex -Bertrand [0] http://www.apache.org/dev/release.html#approving-a-release [1] http://markmail.org/message/4ahntni6kzfnwjzw
RE: [LAST CALL] one week till the release branch is cut
Hey Erik, I'd like to get involved with some of the JIRA issues. Gonna take an easy one to start off with, https://issues.apache.org/jira/browse/FLEX-34336. I wanted to assign it to myself, but I don't see the option when I click on More. I also cannot edit the summary/description etc. Is there something that I need to do to give my JIRA account permissions? Thanks, Chris From: e...@ixsoftware.nl Date: Mon, 8 Dec 2014 10:05:50 +0100 Subject: Re: [LAST CALL] one week till the release branch is cut To: dev@flex.apache.org Hi, Currently these issues are being worked on: - stabilizing TLF - use Apache Flex BlazeDS jar(s) instead of Adobe version And several JIRA issues are assigned and I presume under development. Is someone else working on anything else that they want considered to be part of the next release? Thanks, EdB On Thu, Dec 4, 2014 at 11:41 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, A friendly reminder that we're nearing another milestone towards the 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 09:00), to be precise, I'll cut the release branch. This marks the last opportunity for any features or 'normal' bug fixes to be committed to the repo and be included in the release. If you want to contribute to this release, please consider taking on one of these issues [1], or start checking the documentation and the state of the SDK through the nightlies or from the source in the 'develop' branch. Thank you! EdB 1: https://issues.apache.org/jira/browse/FLEX-34562 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: [RP] When to release?
Yep, same here. I will make best efforts to be available for new releases :) Chris From: aha...@adobe.com To: dev@flex.apache.org Subject: Re: [RP] When to release? Date: Mon, 8 Dec 2014 16:31:41 + Sorry, kept forgetting to reply. I would prefer we not create a schedule. When to release should factor in momentum, importance to the community, even marketing opportunities like conferences. IMO, if a someone wants to take the time and effort to be an RM for a release, and can make the case that the new things in the release are going to be worth the effort to release it, and it won’t take away from momentum of someone else trying to release one of our other packages, then, until my work situation changes, I will always find time to review it (although I may not get to it right away). And if I don’t see enough other folks step up to review that release, until Peter’s work situation changes, I will ask Peter to review it as well. So, at least for now, anyone who wants to be an RM can be pretty sure there will be 3 voters. -Alex On 12/8/14, 5:08 AM, Kessler CTR Mark J mark.kessler@usmc.mil wrote: Should we just leave a one month break, in-between releases and start working on the next one after that? Meaning there could be an SDK release every 2 months or up to 6 times a year. Releases would show minor revisions unless there is a significant addition to the change list. -Start release cycle (takes roughly a month) -After release is complete 1 month to gather more changes. -Start next release cycle. -Mark
Re: Carried RC Votes
Hi Alex, On Mon, Dec 8, 2014 at 5:47 PM, Alex Harui aha...@adobe.com wrote: ...My takeaway is that we can vote +1 without checking everything each time... Definitely, OTOH it's good for voters to briefly indicate what they checked (signatures, build on platform X, etc.) along with their votes - also so that others can fill in the gaps if needed. This helps establish the PMC's overall confidence in how releases are actually checked. So as I said if you checked a release based on a Git tag T1 and a new release is built out of T2 you might just review the T1 - T2 diffs, verify that the T2 archive contents match the T2 Git tag (comparing file digests with a script for example) and be happy to vote +1 on the T2 release without re-checking all the details. ...Are you opposed to having folks who voted +1 on the prior RC offer carryover votes for those next RCs?... I'm actually recommending to drop RCs altogether, just work on individual releases that are either accepted or rejected. If one is rejected, forget it and move to the next version number. Carryover doesn't apply in this case, but people are free to use techniques like outlined above to get the confidence that they need to vote +1 on the new release. In the above example case you might vote +1 saying that you just checked the diffs with T1 that you already checked. -Bertrand
RE: Release guides on Wiki
Thanks Erik for getting the documentation together on this process. May have been a rough road to get this far, but it's well worth it. Liking how it came together. I don't think we need to vote on this one. Everyone worked together to get it where it's at now. And like Om suggested, it's still a work in progress :) We can make adjustments as we go along. Chris From: e...@ixsoftware.nl Date: Mon, 8 Dec 2014 14:04:10 +0100 Subject: Release guides on Wiki To: dev@flex.apache.org Hi, Since it turns out to be not so complicated, I have made some minor adjustments to the release documentation ([1] and [2]), and moved the 'A guide to the Apache Flex release process' article (previously known as the 'less-RC' proposal) to a more accessible location in the wiki. The discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest we use the usual wiki workflow to correct any mistakes. Now, do we vote to codify this? I suggest we don't. If anyone thinks substantive changes are needed - that have not yet been discussed - they are free to turn to the dev@ list, and, if no clear majority for handling it one way or another is clear, start a vote on the proposed changes. EdB 1: https://cwiki.apache.org/confluence/x/2oH0Ag 2: https://cwiki.apache.org/confluence/x/OQDFAQ -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [LAST CALL] one week till the release branch is cut
You need to get JIRA privileges from someone with enough karma ... I think that both Alex and Om have this. I've included them in the To to make sure they receive your request. Thanks for helping out! EdB On Mon, Dec 8, 2014 at 5:56 PM, Chris Martin chrsm...@outlook.com wrote: Hey Erik, I'd like to get involved with some of the JIRA issues. Gonna take an easy one to start off with, https://issues.apache.org/jira/browse/FLEX-34336. I wanted to assign it to myself, but I don't see the option when I click on More. I also cannot edit the summary/description etc. Is there something that I need to do to give my JIRA account permissions? Thanks, Chris From: e...@ixsoftware.nl Date: Mon, 8 Dec 2014 10:05:50 +0100 Subject: Re: [LAST CALL] one week till the release branch is cut To: dev@flex.apache.org Hi, Currently these issues are being worked on: - stabilizing TLF - use Apache Flex BlazeDS jar(s) instead of Adobe version And several JIRA issues are assigned and I presume under development. Is someone else working on anything else that they want considered to be part of the next release? Thanks, EdB On Thu, Dec 4, 2014 at 11:41 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, A friendly reminder that we're nearing another milestone towards the 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 09:00), to be precise, I'll cut the release branch. This marks the last opportunity for any features or 'normal' bug fixes to be committed to the repo and be included in the release. If you want to contribute to this release, please consider taking on one of these issues [1], or start checking the documentation and the state of the SDK through the nightlies or from the source in the 'develop' branch. Thank you! EdB 1: https://issues.apache.org/jira/browse/FLEX-34562 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [LAST CALL] one week till the release branch is cut
Sorry, I don't have those powers. So, Alex, it is on you :-) Thanks, Om On Dec 8, 2014 9:56 AM, Erik de Bruin e...@ixsoftware.nl wrote: You need to get JIRA privileges from someone with enough karma ... I think that both Alex and Om have this. I've included them in the To to make sure they receive your request. Thanks for helping out! EdB On Mon, Dec 8, 2014 at 5:56 PM, Chris Martin chrsm...@outlook.com wrote: Hey Erik, I'd like to get involved with some of the JIRA issues. Gonna take an easy one to start off with, https://issues.apache.org/jira/browse/FLEX-34336. I wanted to assign it to myself, but I don't see the option when I click on More. I also cannot edit the summary/description etc. Is there something that I need to do to give my JIRA account permissions? Thanks, Chris From: e...@ixsoftware.nl Date: Mon, 8 Dec 2014 10:05:50 +0100 Subject: Re: [LAST CALL] one week till the release branch is cut To: dev@flex.apache.org Hi, Currently these issues are being worked on: - stabilizing TLF - use Apache Flex BlazeDS jar(s) instead of Adobe version And several JIRA issues are assigned and I presume under development. Is someone else working on anything else that they want considered to be part of the next release? Thanks, EdB On Thu, Dec 4, 2014 at 11:41 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, A friendly reminder that we're nearing another milestone towards the 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 09:00), to be precise, I'll cut the release branch. This marks the last opportunity for any features or 'normal' bug fixes to be committed to the repo and be included in the release. If you want to contribute to this release, please consider taking on one of these issues [1], or start checking the documentation and the state of the SDK through the nightlies or from the source in the 'develop' branch. Thank you! EdB 1: https://issues.apache.org/jira/browse/FLEX-34562 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: Porting To Typescript/Javascript
1. An overview of the tools would be great. The README does not have a lot to start with. Or, are there any other documentation that I am missing? You don't need to read through all of this, but if you want to get a sense of what it was all about, there are a bunch of tutorials, etc. Most are likely out of date [1]: Basic idea: Combination of a cross-compiler and an SDK using dependency injection and implicit lazy loading of dependencies. You write core AS with a simple DI framework based on the google guice project. The SDK made sure everything was there when it was needed. As you saw, you could then create API definitions (think of the playerglobal.swc) for other dependencies that you were available at runtime, whether they be in the browser itself or in another library that was loaded. 2. I see projects for Ember, JQuery, Node, etc. Does this mean that those frameworks are already supported in Randori? What would it take to add a new framework (DOJO, for example)? Yes, versions of those were all supported. It really just takes creating an API definition with the right metadata so that the compiler understands what code to generate. I would need to get all involved to agree (which wouldn't be hard) but all of Randori was under an Apache license so that, if at any point, this project took an interest in what we did, it would be easy to fold it back in. We didn't want to do it within the Apache process itself, but we always hoped it might end up back here. [1] https://github.com/RandoriAS/randori-plugin-intellij/wiki/Lesson-01-Project-Setup
Next version of Flex SDK
We have a pretty big release coming up [1]. I am wondering if it is time to bump up the version number to 5? As an alternative, we could simply drop the '4' from 4.14.0 and simple start versioning our releases as 14, 15, etc. Technically, we need to make sure that either option would work with IDEs (especially Flash Builder) and our own version checking logic in the SDK. Any thoughts on either of these suggestions? Thanks, Om [1] https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES
Re: Next version of Flex SDK
Didn't Alex find that the current FB requires the leading 4? EdB On Monday, December 8, 2014, OmPrakash Muppirala bigosma...@gmail.com wrote: We have a pretty big release coming up [1]. I am wondering if it is time to bump up the version number to 5? As an alternative, we could simply drop the '4' from 4.14.0 and simple start versioning our releases as 14, 15, etc. Technically, we need to make sure that either option would work with IDEs (especially Flash Builder) and our own version checking logic in the SDK. Any thoughts on either of these suggestions? Thanks, Om [1] https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Question for Flex builder?
Hi Guys, The current version for Flex builder is v 4.7. I just want to know if Adobe will keep release next new version (like version 5 etc) or not. Thanks Mark
RE: Next version of Flex SDK
Hi Om, Despite there are a lot (and it is very relative) bugs fixed, I can't see a good reason why we should go to 5.x, I would even stick on 4.14.x to keep a maximum of amplitude in case big things happen but I'm open to hear why we would go to 4.15.0 Thanks, Frédéric THOMAS From: bigosma...@gmail.com Date: Mon, 8 Dec 2014 12:22:54 -0800 Subject: Next version of Flex SDK To: dev@flex.apache.org We have a pretty big release coming up [1]. I am wondering if it is time to bump up the version number to 5? As an alternative, we could simply drop the '4' from 4.14.0 and simple start versioning our releases as 14, 15, etc. Technically, we need to make sure that either option would work with IDEs (especially Flash Builder) and our own version checking logic in the SDK. Any thoughts on either of these suggestions? Thanks, Om [1] https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES
Re: Next version of Flex SDK
Hi IMO, updating version number from 4 to 5 (or 14 to 15) should be saved for major changes (think halo to spark). New releases that only contain a few new features and bug fixes should be relegated to 0.1 numbers. As for changing the system, my feeling is if it isnt broken dont fix it... we risk confusion for new users with similarly numbered but unconnected AIR/Flash player versions and 'copying' Adobe could hurt perceptions of our independence. Lee Burrows ActionScripter On 08/12/2014 20:22, OmPrakash Muppirala wrote: We have a pretty big release coming up [1]. I am wondering if it is time to bump up the version number to 5? As an alternative, we could simply drop the '4' from 4.14.0 and simple start versioning our releases as 14, 15, etc. Technically, we need to make sure that either option would work with IDEs (especially Flash Builder) and our own version checking logic in the SDK. Any thoughts on either of these suggestions? Thanks, Om [1] https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES
Re: Question for Flex builder?
Its highly unlikely that there will ever be a new version of Flash(Flex) Builder. Its not on Adobe's roadmap. Lee Burrows ActionScripter On 08/12/2014 20:39, Mark Shen wrote: Hi Guys, The current version for Flex builder is v 4.7. I just want to know if Adobe will keep release next new version (like version 5 etc) or not. Thanks Mark
Re: Next version of Flex SDK
I know I'm just some bro on the list here but I'd agree. I don't think you want to turn the SDK into firefox/chrome, where every time they push the build button it goes up a full revision. In a month we'll all be browsing with firefox/chrome 135. On Mon, Dec 8, 2014 at 4:04 PM, Subscriptions subscripti...@leeburrows.com wrote: Hi IMO, updating version number from 4 to 5 (or 14 to 15) should be saved for major changes (think halo to spark). New releases that only contain a few new features and bug fixes should be relegated to 0.1 numbers. As for changing the system, my feeling is if it isnt broken dont fix it... we risk confusion for new users with similarly numbered but unconnected AIR/Flash player versions and 'copying' Adobe could hurt perceptions of our independence. Lee Burrows ActionScripter On 08/12/2014 20:22, OmPrakash Muppirala wrote: We have a pretty big release coming up [1]. I am wondering if it is time to bump up the version number to 5? As an alternative, we could simply drop the '4' from 4.14.0 and simple start versioning our releases as 14, 15, etc. Technically, we need to make sure that either option would work with IDEs (especially Flash Builder) and our own version checking logic in the SDK. Any thoughts on either of these suggestions? Thanks, Om [1] https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES -- Jesse Nicholson
Re: Next version of Flex SDK
I’m not a big fan of xx.xx.xx.xx, but I do not see why it should go from 4 to 5. The stability of the major version number in Flex is well grounded. I’d vote to just make it 4.15 and keep upping the minor number with each release. The only reason to make a 4.15.1 release (or the like) would be for a hot fix of a problematic release. Harbs
[RESULT][VOTE] Allow RC votes to carry over at any point in the release process
This vote passed with 6 +1 binding votes and one -1 binding votes. This vote is somewhat moot in light of the recent discussions and clarifications of what different people mean by “carried votes”, but I will edit the guidelines shortly to reflect what I believe was the spirit of the vote. If anyone has concerns with the wording, please raise them in another thread. Thanks, Harbs
[RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
Raising visibility :-) -- Forwarded message -- From: *Harbs* harbs.li...@gmail.com Date: Monday, December 8, 2014 Subject: [VOTE] Allow RC votes to carry over at any point in the release process To: dev@flex.apache.org dev@flex.apache.org This vote passed with 6 +1 binding votes and one -1 binding votes. This vote is somewhat moot in light of the recent discussions and clarifications of what different people mean by “carried votes”, but I will edit the guidelines shortly to reflect what I believe was the spirit of the vote. If anyone has concerns with the wording, please raise them in another thread. Thanks, Harbs -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [RESULT][VOTE] Allow RC votes to carry over at any point in the release process
Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
That’s odd. I added [Result] to the subject when I sent it… Anyway, thanks. On Dec 9, 2014, at 12:04 AM, Erik de Bruin e...@ixsoftware.nl wrote: Raising visibility :-) -- Forwarded message -- From: *Harbs* harbs.li...@gmail.com Date: Monday, December 8, 2014 Subject: [VOTE] Allow RC votes to carry over at any point in the release process To: dev@flex.apache.org dev@flex.apache.org This vote passed with 6 +1 binding votes and one -1 binding votes. This vote is somewhat moot in light of the recent discussions and clarifications of what different people mean by “carried votes”, but I will edit the guidelines shortly to reflect what I believe was the spirit of the vote. If anyone has concerns with the wording, please raise them in another thread. Thanks, Harbs -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Next version of Flex SDK
I think you¹d want to go to a new major version if something really significant changed. For example, an entirely new MXML (e.g., FlexJS became to default) or major changes to ActionScript. Simply adding new components and fixed bugs does not, to me, warrant a bump in version from 4 to 5. Peter Ent Adobe Systems On 12/8/14, 4:41 PM, Harbs harbs.li...@gmail.com wrote: I¹m not a big fan of xx.xx.xx.xx, but I do not see why it should go from 4 to 5. The stability of the major version number in Flex is well grounded. I¹d vote to just make it 4.15 and keep upping the minor number with each release. The only reason to make a 4.15.1 release (or the like) would be for a hot fix of a problematic release. Harbs
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines
RE: Next version of Flex SDK
+1 with that Peter Btw, have you also switched to Outlook as I can see the ' are replaced with ¹ ? Frédéric THOMAS From: p...@adobe.com To: dev@flex.apache.org Subject: Re: Next version of Flex SDK Date: Mon, 8 Dec 2014 22:18:26 + I think you¹d want to go to a new major version if something really significant changed. For example, an entirely new MXML (e.g., FlexJS became to default) or major changes to ActionScript. Simply adding new components and fixed bugs does not, to me, warrant a bump in version from 4 to 5. Peter Ent Adobe Systems On 12/8/14, 4:41 PM, Harbs harbs.li...@gmail.com wrote: I¹m not a big fan of xx.xx.xx.xx, but I do not see why it should go from 4 to 5. The stability of the major version number in Flex is well grounded. I¹d vote to just make it 4.15 and keep upping the minor number with each release. The only reason to make a 4.15.1 release (or the like) would be for a hot fix of a problematic release. Harbs
Re: [LAST CALL] one week till the release branch is cut
Hi Chris, Sorry for the delay, you should be able to assign issues to yourself now. Does any PMC member want JIRA project admin karma so they can also do more things? Currently , Justin, Chris Dutz, and I are the only admins who you hear from on a regular basis. -Alex From: OmPrakash Muppirala bigosma...@gmail.commailto:bigosma...@gmail.com Date: Monday, December 8, 2014 at 10:06 AM To: e...@ixsoftware.nlmailto:e...@ixsoftware.nl e...@ixsoftware.nlmailto:e...@ixsoftware.nl Cc: Alex Harui aha...@adobe.commailto:aha...@adobe.com, dev@flex.apache.orgmailto:dev@flex.apache.org dev@flex.apache.orgmailto:dev@flex.apache.org Subject: Re: [LAST CALL] one week till the release branch is cut Sorry, I don't have those powers. So, Alex, it is on you :-) Thanks, Om On Dec 8, 2014 9:56 AM, Erik de Bruin e...@ixsoftware.nlmailto:e...@ixsoftware.nl wrote: You need to get JIRA privileges from someone with enough karma ... I think that both Alex and Om have this. I've included them in the To to make sure they receive your request. Thanks for helping out! EdB On Mon, Dec 8, 2014 at 5:56 PM, Chris Martin chrsm...@outlook.commailto:chrsm...@outlook.com wrote: Hey Erik, I'd like to get involved with some of the JIRA issues. Gonna take an easy one to start off with, https://issues.apache.org/jira/browse/FLEX-34336. I wanted to assign it to myself, but I don't see the option when I click on More. I also cannot edit the summary/description etc. Is there something that I need to do to give my JIRA account permissions? Thanks, Chris From: e...@ixsoftware.nlmailto:e...@ixsoftware.nl Date: Mon, 8 Dec 2014 10:05:50 +0100 Subject: Re: [LAST CALL] one week till the release branch is cut To: dev@flex.apache.orgmailto:dev@flex.apache.org Hi, Currently these issues are being worked on: - stabilizing TLF - use Apache Flex BlazeDS jar(s) instead of Adobe version And several JIRA issues are assigned and I presume under development. Is someone else working on anything else that they want considered to be part of the next release? Thanks, EdB On Thu, Dec 4, 2014 at 11:41 AM, Erik de Bruin e...@ixsoftware.nlmailto:e...@ixsoftware.nl wrote: Hi, A friendly reminder that we're nearing another milestone towards the 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 09:00), to be precise, I'll cut the release branch. This marks the last opportunity for any features or 'normal' bug fixes to be committed to the repo and be included in the release. If you want to contribute to this release, please consider taking on one of these issues [1], or start checking the documentation and the state of the SDK through the nightlies or from the source in the 'develop' branch. Thank you! EdB 1: https://issues.apache.org/jira/browse/FLEX-34562 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nlhttp://www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nlhttp://www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nlhttp://www.ixsoftware.nl
Re: [CONF] Apache Flex A guide to the Apache Flex release process
Hi Jesse, Truly, thank you for this kind of feedback. I hope you continue to be honest about your perception of the project and community. I am hopeful we’ll close this particular issue down soon. Thanks, -Alex On 12/8/14, 7:01 AM, Jesse Nicholson ascensionsyst...@gmail.com wrote: Honestly guys this is getting ridiculous, it's been days now. I'm actually considering making a world war 2 style documentary about this. Battle For The Button: Release. Synopsis: Join us as we recount the riveting tale of one mans battle against an army of contributors. He single-handedly repelled the efforts and input of absolutely everyone to maintain control the publish release button. What do think? For the sequel, it's still up in the air, but I'm playing with a title: Apache Flex - Dead At Version 4.13. Or maybe Apache Flex 4.13 - Over 9000 Commits Behind Master Hopefully this is over before I hit the spam button. On Mon, Dec 8, 2014 at 9:40 AM, Erik de Bruin e...@ixsoftware.nl wrote: Sorry Tom, we seem to have crossed our beams. Let's hope we didn't accidentally destroy the universe and somehow are not (yet) aware of it ;-) Thanks, EdB On Mon, Dec 8, 2014 at 2:40 PM, Tom Chiverton t...@extravision.com wrote: On 08/12/14 13:24, Justin Mclean wrote: that's not Apache policy. What did Bertrand *just say* in the post with subject [TTH] it's not that complicated ? Stuff like this *doesn't have an Apache policy*. It's also very unclear who you were responding too and about what. Probably because you are replying to a bounce message or something, I think ? Assuming you mean some minor point that you feel hasn't been discussed enough in the new release process we're adopting, why does what Erik suggested (my emphasis): discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest *we use the usual wiki workflow to correct any mistakes* not apply ? You could just have noted this one sentence needed clearing up there and saved some time here for everyone else ? Please consider reviewing your vote, Tom -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Jesse Nicholson
Re: Next version of Flex SDK
I'm wondering how close you are to having a version ready for committed development. Please let me know. Thanks!
Re: [CONF] Apache Flex A guide to the Apache Flex release process
lol I'm a little overkill with sarcasm and not everyone enjoys that. I apologize if I've offended anyone. Sooner or later, I'll contribute something more than sarcasm and sideline comments to this project. :) I do definitely plan on contributing (code that is, this is the real reason I joined the dev list), just tied up with other stuff right now. On Mon, Dec 8, 2014 at 6:01 PM, Alex Harui aha...@adobe.com wrote: Hi Jesse, Truly, thank you for this kind of feedback. I hope you continue to be honest about your perception of the project and community. I am hopeful we’ll close this particular issue down soon. Thanks, -Alex On 12/8/14, 7:01 AM, Jesse Nicholson ascensionsyst...@gmail.com wrote: Honestly guys this is getting ridiculous, it's been days now. I'm actually considering making a world war 2 style documentary about this. Battle For The Button: Release. Synopsis: Join us as we recount the riveting tale of one mans battle against an army of contributors. He single-handedly repelled the efforts and input of absolutely everyone to maintain control the publish release button. What do think? For the sequel, it's still up in the air, but I'm playing with a title: Apache Flex - Dead At Version 4.13. Or maybe Apache Flex 4.13 - Over 9000 Commits Behind Master Hopefully this is over before I hit the spam button. On Mon, Dec 8, 2014 at 9:40 AM, Erik de Bruin e...@ixsoftware.nl wrote: Sorry Tom, we seem to have crossed our beams. Let's hope we didn't accidentally destroy the universe and somehow are not (yet) aware of it ;-) Thanks, EdB On Mon, Dec 8, 2014 at 2:40 PM, Tom Chiverton t...@extravision.com wrote: On 08/12/14 13:24, Justin Mclean wrote: that's not Apache policy. What did Bertrand *just say* in the post with subject [TTH] it's not that complicated ? Stuff like this *doesn't have an Apache policy*. It's also very unclear who you were responding too and about what. Probably because you are replying to a bounce message or something, I think ? Assuming you mean some minor point that you feel hasn't been discussed enough in the new release process we're adopting, why does what Erik suggested (my emphasis): discussion on the process itself has already taken place on this list and the result is the article in it's current revision. I suggest *we use the usual wiki workflow to correct any mistakes* not apply ? You could just have noted this one sentence needed clearing up there and saved some time here for everyone else ? Please consider reviewing your vote, Tom -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Jesse Nicholson -- Jesse Nicholson
Re: [LAST CALL] one week till the release branch is cut
On Dec 8, 2014 2:47 PM, Alex Harui aha...@adobe.com wrote: Hi Chris, Sorry for the delay, you should be able to assign issues to yourself now. Does any PMC member want JIRA project admin karma so they can also do more things? Currently , Justin, Chris Dutz, and I are the only admins who you hear from on a regular basis. I can take up admin role. Thanks, Om -Alex From: OmPrakash Muppirala bigosma...@gmail.com Date: Monday, December 8, 2014 at 10:06 AM To: e...@ixsoftware.nl e...@ixsoftware.nl Cc: Alex Harui aha...@adobe.com, dev@flex.apache.org dev@flex.apache.org Subject: Re: [LAST CALL] one week till the release branch is cut Sorry, I don't have those powers. So, Alex, it is on you :-) Thanks, Om On Dec 8, 2014 9:56 AM, Erik de Bruin e...@ixsoftware.nl wrote: You need to get JIRA privileges from someone with enough karma ... I think that both Alex and Om have this. I've included them in the To to make sure they receive your request. Thanks for helping out! EdB On Mon, Dec 8, 2014 at 5:56 PM, Chris Martin chrsm...@outlook.com wrote: Hey Erik, I'd like to get involved with some of the JIRA issues. Gonna take an easy one to start off with, https://issues.apache.org/jira/browse/FLEX-34336 . I wanted to assign it to myself, but I don't see the option when I click on More. I also cannot edit the summary/description etc. Is there something that I need to do to give my JIRA account permissions? Thanks, Chris From: e...@ixsoftware.nl Date: Mon, 8 Dec 2014 10:05:50 +0100 Subject: Re: [LAST CALL] one week till the release branch is cut To: dev@flex.apache.org Hi, Currently these issues are being worked on: - stabilizing TLF - use Apache Flex BlazeDS jar(s) instead of Adobe version And several JIRA issues are assigned and I presume under development. Is someone else working on anything else that they want considered to be part of the next release? Thanks, EdB On Thu, Dec 4, 2014 at 11:41 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, A friendly reminder that we're nearing another milestone towards the 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 09:00), to be precise, I'll cut the release branch. This marks the last opportunity for any features or 'normal' bug fixes to be committed to the repo and be included in the release. If you want to contribute to this release, please consider taking on one of these issues [1], or start checking the documentation and the state of the SDK through the nightlies or from the source in the 'develop' branch. Thank you! EdB 1: https://issues.apache.org/jira/browse/FLEX-34562 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines
Re:Question for Flex builder?
Hi, The best Flash Builder alternative is FDT, but it does not support MXML Design View. http://fdt.powerflasher.com/ The 2nd choice is IntelliJ IDEA, you can download a MXML Design View plugin, it's very cool. http://www.jetbrains.com/idea/features/flex_ide.html The 3rd choice is FlashDevelop, it's free and open sourced, but it's Windows only, and it does not support MXML Design View either. http://www.flashdevelop.org/ DarkStone 2014-12-09 At 2014-12-09 04:39:37, Mark Shen markshen2...@gmail.com wrote: Hi Guys, The current version for Flex builder is v 4.7. I just want to know if Adobe will keep release next new version (like version 5 etc) or not. Thanks Mark
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
Agreed. We need broad language that represents the idea, not legalese that tries to capture all eventuallities. I'll make some modifications to the wiki if nobody beats me to it. Before we get into too long a discussion, please remember this is pretty much obsolete with the new voting guidelines. EdB On Tuesday, December 9, 2014, Alex Harui aha...@adobe.com wrote: Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com javascript:; wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
Done. I added a sentence defining “carrying” as “oversight”. On Dec 9, 2014, at 2:18 AM, Alex Harui aha...@adobe.com wrote: Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
I had to read the 'oversight' line twice to catch it's meaning. I have suggested an alternative, please take a look. EdB On Tue, Dec 9, 2014 at 7:58 AM, Harbs harbs.li...@gmail.com wrote: Done. I added a sentence defining “carrying” as “oversight”. On Dec 9, 2014, at 2:18 AM, Alex Harui aha...@adobe.com wrote: Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
It looks fine to me. On Dec 9, 2014, at 9:11 AM, Erik de Bruin e...@ixsoftware.nl wrote: I had to read the 'oversight' line twice to catch it's meaning. I have suggested an alternative, please take a look. EdB On Tue, Dec 9, 2014 at 7:58 AM, Harbs harbs.li...@gmail.com wrote: Done. I added a sentence defining “carrying” as “oversight”. On Dec 9, 2014, at 2:18 AM, Alex Harui aha...@adobe.com wrote: Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
Crud, Unfortunately, I didn’t like either offering. It can’t be the “same” due diligence since the requestor didn’t examine the current artifacts. I say we either: 1) remove it entirely. This simplifies the guidelines but may complicate a situation where we don’t have enough voters with enough time. Maybe we should gamble on that and discuss carryover should we ever need it. 2) Require that folks requesting carry over state how they conclude the bits are good (based on git logs, reports from those who did vote, maybe that they didn’t agree the issue was critical in the first place). This would provide a “paper trail”. 3) Not have any additional sentence per my first proposal and trust folks to use carryover properly 4) Keep trying to find better words. 5) Go with Erik’s version anyway. Right now I like option #1. -Alex On 12/8/14, 11:11 PM, Erik de Bruin e...@ixsoftware.nl wrote: I had to read the 'oversight' line twice to catch it's meaning. I have suggested an alternative, please take a look. EdB On Tue, Dec 9, 2014 at 7:58 AM, Harbs harbs.li...@gmail.com wrote: Done. I added a sentence defining “carrying” as “oversight”. On Dec 9, 2014, at 2:18 AM, Alex Harui aha...@adobe.com wrote: Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the release process
Alright. I just removed the entire line. It jives with what Bertrand suggested anyways. Let’s try to avoid “carried votes” and just go with simplified revoting… From my perspective we’ve spent more than enough time on a really insignificant issue. On Dec 9, 2014, at 9:45 AM, Alex Harui aha...@adobe.com wrote: Crud, Unfortunately, I didn’t like either offering. It can’t be the “same” due diligence since the requestor didn’t examine the current artifacts. I say we either: 1) remove it entirely. This simplifies the guidelines but may complicate a situation where we don’t have enough voters with enough time. Maybe we should gamble on that and discuss carryover should we ever need it. 2) Require that folks requesting carry over state how they conclude the bits are good (based on git logs, reports from those who did vote, maybe that they didn’t agree the issue was critical in the first place). This would provide a “paper trail”. 3) Not have any additional sentence per my first proposal and trust folks to use carryover properly 4) Keep trying to find better words. 5) Go with Erik’s version anyway. Right now I like option #1. -Alex On 12/8/14, 11:11 PM, Erik de Bruin e...@ixsoftware.nl wrote: I had to read the 'oversight' line twice to catch it's meaning. I have suggested an alternative, please take a look. EdB On Tue, Dec 9, 2014 at 7:58 AM, Harbs harbs.li...@gmail.com wrote: Done. I added a sentence defining “carrying” as “oversight”. On Dec 9, 2014, at 2:18 AM, Alex Harui aha...@adobe.com wrote: Maybe I’m being too picky, but the vote proposal said: I suggest that at any point in the release process a vote should be carried over if the person voting indicates they wish the vote should carry over.” The current wiki version says: The release manager can carry over of votes from previous release candidates to the new release candidate if changes between release candidates contain no code changes or changes to legally significant documents.” I would suggest either removing that section entirely and hoping we always have enough folks willing to re-check, or re-wording to: “If a PMC member voted on a release candidate, and the release manager creates a new one, the PMC member can state that they want their vote to be carried over”. And I would suggest moving that point below the one that says that you don’t have to re-check everything (since re-checking changes is preferred). I wouldn't put any qualifications on what changes do or don’t qualify for carryover. I trust each PMC member to be a good judge of when a carryover is proper, and we can avoid later arguments on what constitutes a code change. -Alex On 12/8/14, 2:18 PM, Harbs harbs.li...@gmail.com wrote: I don’t see my last two emails in the archives. Sorry if this is going out more than once… Here is a link to the modified wiki.[1] I think the changes are pretty minor… I removed mention of carried votes from the voting timeframe section, and clarified the wording in the “Product Release” section. Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
