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 wrote:

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

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 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 wrote: >> Done. I added a sentence defining “c

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 wrote: > Done. I added a sentence defining “carrying” as “oversight”. > > On Dec 9, 2014, at 2:18 AM, Alex Harui wrote: > >> Maybe I’m

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 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 v

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.

RE: Next version of Flex SDK

Thanks for the feedback, folks. So, 4.14.0, it is :-) Thanks, Om On Dec 8, 2014 2:25 PM, "Frédéric THOMAS" wrote: > +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

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 FlashDevel

new themes in 4.14

Hi All, Can somebody point me to instructions for building/using the new themes in 4.14? (ios, android, flat). Thanks, -- Lee Burrows ActionScripter

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 r

Re: [LAST CALL] one week till the release branch is cut

Hi Om, I added you to the admin list. Give it a try. -Alex From: OmPrakash Muppirala mailto:bigosma...@gmail.com>> Date: Monday, December 8, 2014 at 3:28 PM To: Alex Harui mailto:aha...@adobe.com>> Cc: Erik de Bruin mailto:e...@ixsoftware.nl>>, "dev@flex.apache.org"

Re: [LAST CALL] one week till the release branch is cut

On Dec 8, 2014 2:47 PM, "Alex Harui" 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 fro

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 d

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

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" wrote: >Honestly guys this is getting ridi

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 Muppira

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

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” secti

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 E

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 wrote: > Raising visibility :-) > > -- Forwarded message -- > From: *Harbs* > Date: Monday, December 8, 2014 > Subject: [VOTE] Allow RC votes to carry over at

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

[RESULT][VOTE] - Allow RC votes to carry over at any point in the release process

Raising visibility :-) -- Forwarded message -- From: *Harbs* 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" This vote passed with 6 +1 binding votes and one -1 binding votes. This vote i

[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 a

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 f

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 wrot

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 versio

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

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.

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

Didn't Alex find that the current FB requires the leading 4? EdB On Monday, December 8, 2014, 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

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 I

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 a

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" 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 re

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 wrote: > Hey Erik, > > I'd like to get invo

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

Re: Carried RC Votes

Hi Alex, On Mon, Dec 8, 2014 at 5:47 PM, Alex Harui 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 o

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. > Wh

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. I

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" wrote: >Git or svn diffs will show how much changed between that new release >and the one that fail

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"

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 th

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 repel

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 wrote: > On 08/12/14 13:24, Justin Mclean wrote: >> >> that's not Apache policy. > > What di

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 wi

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 a

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 interes

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 re

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

[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 th

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

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

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/extens

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? T