Re: [DISCUSS] How do we want to handle Whiteboard?
Hi, Assuming we get the git hub mirrors up and working there nothing stopping anyone from using github to supply patches and diff in the usual way. A git hub pull request can be converted directly into a patch file and applied easily. There's one outstanding issue in how do we close pull requests, I asked this before but no one seem to know the answer. I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Thanks, Justin
Re: General Questions on committing code
Hi, Besides adding dataProvider support to make it functionally equivalent to the mx one, I added support for no color and proper handling of null objects in the dataProvider (to indicate no color). Although it seems to work correctly for my personal use, I have not done extensive testing. Should I commit the code as-is, and hope it works/will be better tested later? Wait? Something else? I'm just not sure on proper procedure here… Policy is commit first and review second.Having more eyes on it will improve the quality. The experimental namespace is exactly for components like that that ie functional but not fully tested. Also, is there a policy on code formatting? Do we care that all code formatting styles match? It's nice that the code formatting matches the existing SDK code where possible (and yes there's inconsistencies). If yes, is there a document on this somewhere? There was some Adobe documentation a search of the mailing list should find it. Thanks, Justin
Still confused by git
I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -Checkout the develop branch: git co develop -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
oops, reverse the 2 furst steps: -If you have some modified files in your working tree, save them first: git stash -u my current work -Checkout the develop branch: git co develop -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:31 AM To: dev@flex.apache.org Subject: Re: Still confused by git You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
git: 'st' is not a git command. See 'git --help'. Did you mean one of these? status reset stage stash svn On Apr 5, 2013, at 12:41 PM, Frédéric THOMAS wrote: The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine I just noticed you wrote that, can you show me the result of 'git st' ? -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:33 AM To: dev@flex.apache.org Subject: Re: Still confused by git oops, reverse the 2 furst steps: -If you have some modified files in your working tree, save them first: git stash -u my current work -Checkout the develop branch: git co develop -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:31 AM To: dev@flex.apache.org Subject: Re: Still confused by git You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
I mean git status, but if you want to follow the commands I wrote, update your .gitconfig as described in the wiki -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:59 AM To: dev@flex.apache.org Subject: Re: Still confused by git git: 'st' is not a git command. See 'git --help'. Did you mean one of these? status reset stage stash svn On Apr 5, 2013, at 12:41 PM, Frédéric THOMAS wrote: The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine I just noticed you wrote that, can you show me the result of 'git st' ? -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:33 AM To: dev@flex.apache.org Subject: Re: Still confused by git oops, reverse the 2 furst steps: -If you have some modified files in your working tree, save them first: git stash -u my current work -Checkout the develop branch: git co develop -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:31 AM To: dev@flex.apache.org Subject: Re: Still confused by git You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all
Re: Still confused by git
Thanks. I'll have to figure out how to translate that into the GUI of SourceTree. I'm not sure if I have the time today to play around with this. I'll probably get to it on Sunday… How do I know which branch the working copy is using and how do I switch? I started looking at tutorials, but this stuff is really not intuitive to me… :-( I'm just hoping I'll be glad I learned git when this is all over… ;-) Harbs On Apr 5, 2013, at 12:33 PM, Frédéric THOMAS wrote: oops, reverse the 2 furst steps: -If you have some modified files in your working tree, save them first: git stash -u my current work -Checkout the develop branch: git co develop -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:31 AM To: dev@flex.apache.org Subject: Re: Still confused by git You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
RE: Still confused by git
I still recommend Tortoise Git [1] to all new people running Windows... no command line needed (thank goodness). Just need to install MSysGit [2] as a pre-requisite and you're up and running. [1] http://code.google.com/p/tortoisegit/ [2] http://code.google.com/p/msysgit/downloads/list?q=net+installer -Mark -Original Message- From: Justin Mclean [mailto:jus...@classsoftware.com] Sent: Friday, April 05, 2013 5:45 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi, There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. I don't believe there is a consensus but that's mostly around how important it is to keep a clean history and with respect to Frederic obvious knowledge in this area we still need to come up with a way people new to git can contribute without knowing every intricate details of obscure options to git commands. In part because not everyone will use the command line. Thanks, Justin
Re: Still confused by git
SourceTree gives you access to the command line, I suggest you to start with the command line, once those basics commands known, that will then become easy to do it in sourceTree, in more, I can't teach you how to do that with sourceTree unless I do a screencast. -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 12:02 PM To: dev@flex.apache.org Subject: Re: Still confused by git Thanks. I'll have to figure out how to translate that into the GUI of SourceTree. I'm not sure if I have the time today to play around with this. I'll probably get to it on Sunday… How do I know which branch the working copy is using and how do I switch? I started looking at tutorials, but this stuff is really not intuitive to me… :-( I'm just hoping I'll be glad I learned git when this is all over… ;-) Harbs On Apr 5, 2013, at 12:33 PM, Frédéric THOMAS wrote: oops, reverse the 2 furst steps: -If you have some modified files in your working tree, save them first: git stash -u my current work -Checkout the develop branch: git co develop -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, April 05, 2013 11:31 AM To: dev@flex.apache.org Subject: Re: Still confused by git You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do
Re: Still confused by git
I'm already stuck with the second step: git pull --rebase Cannot pull with rebase: Your index contains uncommitted changes. Please commit or stash them. I do not want any changes -- since I did not make any! What do I do? On Apr 5, 2013, at 12:31 PM, Frédéric THOMAS wrote: You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -Checkout the develop branch: git co develop -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
Re: Still confused by git
Okay. I did it. It looks like I slightly messed up the last step. Sorry about that. I used SourceTree for the last step because I was not interested in typing my password into Terminal. I think there's a checkbox to push all tags that I should have unchecked… Thanks for the hand-holding on this… :-) Harbs On Apr 5, 2013, at 12:31 PM, Frédéric THOMAS wrote: You right Harbs, that currently looks something I dislike at the point I won't work anymore on that tree. Well, for your case (I assume you updated your .gitconfig as shown in the Wiki) : -Checkout the develop branch: git co develop -If you have some modified files in your working tree, save them first: git stash -u my current work -Be sure the branch is up to date before to start working on it: git pull --rebase -create the branch you will work on, assuming your create a JIRA first: git co -b FLEX- -get back the work you save on this branch: git stash pop -Edit/add files/dirs -Add them to the staged area(also called index) and commit, you've got 2 choices, either you do 1 commit or more: 1- To add all of them in a once, that's in order to do only one commit: - git add . - git ci -m FLEX-: Fixed this 2- To add them one by one, that's in order to make more commits - git add myFile1 myFile2 - git ci -m FLEX-: Fixed this in my 1rst commit - git add myFile3 myFile4 - git ci -m FLEX-: Fixed this in my 2nd commit - check all the files are committed: git st - If there are more repeat the add/commit steps, otherwise, go back on the develop branch: git co develop - rebase your work on what the others did: git pull --rebase - Merge your branch to the develop one: git merge --no-ff FLEX- - you can now push: git push - you can remove your local branch if you want now it is unused: git br -d FLEX- I hope that helps -Fred -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 11:06 AM To: dev@flex.apache.org Subject: Re: Still confused by git Hi Fred, I've read those pages. (I see now you've updated them.) Conceptually, I sort of got the idea of how to do things, but I find that until I actually do something once, I don't quite get it… If someone could walk me through this once, I think I'l be a lot more comfortable that I'm doing things right. There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. Looking at the graph, it seems to me that not everyone is working exactly the same way. (unless I don't know how to read the graph, which is also possible…) On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote: Hi Harbs, Check the wiki first for a complete workflow guideline and git setup, if you need more info, ask them after you reviewed this wiki pages [1] [2], there are even interactive tutorials really well done. [1] [2] I advice that to everybody, for myself, until everyone understood and applied the basics written in the wiki, I won't touch the SDK anymore. -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Harbs Sent: Friday, April 05, 2013 10:14 AM To: dev@flex.apache.org Subject: Still confused by git I've tried to follow all the git discussions. But, after all the discussions on how to use git, I'm still confused on the basics. Here's what I need to know right now: Right now I have a number of files I've edited outside my working directory related to ColorPicker inside experimental. I'd like to commit this work to the develop branch. It probably makes sense to create a branch to indicate the work I'm doing on this. (or not?) I'm using SourceTree on Mac. I'd rather not mess with the command line. So far I've checked out develop and master. The index view shows a bunch of modified and deleted files. I have not yet touched any of the git folders on my machine. How do I? 1) Make sure my working copy is up to date? 2) Make sure my working coy is the correct branch? (Does that make sense?) 3) Create a new branch? (Or do I?) 4) Get my changes up to origin? I've seen a lot of talk about switching between branches, but this stuff is all very fuzzy to me and kind of scary… ;-) Harbs
[jira] [Commented] (FLEX-33451) The release build due to the Git migration is broken
[ https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13623561#comment-13623561 ] Frédéric THOMAS commented on FLEX-33451: - ASDoc for the experimental lib (Not fixed, just commented at the moment - Build Number (Not fixed) Please, open a new issue for those 2 remaining ones, the branch relative to this one had been merged The release build due to the Git migration is broken Key: FLEX-33451 URL: https://issues.apache.org/jira/browse/FLEX-33451 Project: Apache Flex Issue Type: Bug Components: .Unspecified - Framework Affects Versions: Adobe Flex SDK Next Reporter: Frédéric THOMAS Assignee: Frédéric THOMAS Priority: Critical Labels: Git, TLF, build, documentation The release build due to the Git migration is broken: - TLF external build - Build Number - ASDoc for the experimental lib - Building process (.gitignore, empty.properties) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FLEX-33451) The release build due to the Git migration is broken
[ https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS resolved FLEX-33451. Resolution: Fixed The release build due to the Git migration is broken Key: FLEX-33451 URL: https://issues.apache.org/jira/browse/FLEX-33451 Project: Apache Flex Issue Type: Bug Components: .Unspecified - Framework Affects Versions: Adobe Flex SDK Next Reporter: Frédéric THOMAS Assignee: Frédéric THOMAS Priority: Critical Labels: Git, TLF, build, documentation The release build due to the Git migration is broken: - TLF external build - Build Number - ASDoc for the experimental lib - Building process (.gitignore, empty.properties) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FLEX-33316) checkintests fails on no english OS
[ https://issues.apache.org/jira/browse/FLEX-33316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS resolved FLEX-33316. Resolution: Fixed checkintests fails on no english OS --- Key: FLEX-33316 URL: https://issues.apache.org/jira/browse/FLEX-33316 Project: Apache Flex Issue Type: Bug Components: Mustella Reporter: Frédéric THOMAS Assignee: Frédéric THOMAS Priority: Trivial Labels: mustella, test checkintests fails on no english OS, feel free to use this jira tickect to link with your commit if you checked in a fix for your language. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Still confused by git
+1 on this. I've been sitting on the sidelines the last few weeks for that reason. I know there are a lot of standards that still need to be figured out, and since I'm very green with GIT, I don't really have the time at the moment to learn all the command line (i've been really busy with personal and professional stuff the last few weeks as well). My goal is not to use the command line, but use my IDE like I did before. Dropping to the command line and typing 10 commands every time I want to do something is a pain in the rear for those things that my IDE should be doing for me (I usually have a dozen command prompt windows open at any given time, but those are for truly interactive things). -Nick On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean jus...@classsoftware.comwrote: Hi, There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. I don't believe there is a consensus but that's mostly around how important it is to keep a clean history and with respect to Frederic obvious knowledge in this area we still need to come up with a way people new to git can contribute without knowing every intricate details of obscure options to git commands. In part because not everyone will use the command line. Thanks, Justin
[jira] [Resolved] (FLEX-33435) Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN
[ https://issues.apache.org/jira/browse/FLEX-33435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS resolved FLEX-33435. Resolution: Fixed Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN - Key: FLEX-33435 URL: https://issues.apache.org/jira/browse/FLEX-33435 Project: Apache Flex Issue Type: Bug Components: Web Site Reporter: Justin Mclean Assignee: Frédéric THOMAS Pages that need updating include: http://flex.apache.org/dev-faq.html http://flex.apache.org/dev-sourcecode.html http://flex.apache.org/download-source.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33422) Typo in the French translation for the SDK Installer: Installation terminer
[ https://issues.apache.org/jira/browse/FLEX-33422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS closed FLEX-33422. -- Typo in the French translation for the SDK Installer: Installation terminer - Key: FLEX-33422 URL: https://issues.apache.org/jira/browse/FLEX-33422 Project: Apache Flex Issue Type: Bug Components: InstallApacheFlex Environment: apache-flex-sdk-installer-2.0.2-bin.exe Reporter: Frédéric Leroy Assignee: Frédéric THOMAS Priority: Trivial Labels: easyfix, french, installer, translation Installation terminer should be: Installation terminée -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33377) Focus can be transferred from a modal window to a non-modal window open in the background if clicked on some specific dimension of the non-modal window in the background i
[ https://issues.apache.org/jira/browse/FLEX-33377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS closed FLEX-33377. -- Focus can be transferred from a modal window to a non-modal window open in the background if clicked on some specific dimension of the non-modal window in the background i.e. by clicking on the extreme left i.e. x=0 dimension of the application. - Key: FLEX-33377 URL: https://issues.apache.org/jira/browse/FLEX-33377 Project: Apache Flex Issue Type: Bug Components: mx: Window Affects Versions: Adobe Flex SDK 4.6 (Release) Environment: Web application, flex SDK 4.6. and 4.9 Flash player version: 11.5.502.146 Mozilla firefox and IE Reporter: rahul singh rawat Assignee: Frédéric THOMAS Priority: Minor Attachments: Modal_mxTest.fxp, Modal_mxTest-MonkeyPatched.fxp Focus can be transferred from a modal window to a non-modal window open in the background if clicked ONLY on some specific dimension of the non-modal window in the background i.e. by clicking on the extreme left i.e. x=0 dimension of the application. Issue varies with flash player versions and browser used. The non-modal window is coded to listen to a click event. However it can be easily reproduced with any browser or flash player version by setting the x dimension of the non-modal window between-10 to 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FLEX-33386) Style Declaration Matching Tuning - Inlining
[ https://issues.apache.org/jira/browse/FLEX-33386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS updated FLEX-33386: --- Assignee: (was: Frédéric THOMAS) Style Declaration Matching Tuning - Inlining Key: FLEX-33386 URL: https://issues.apache.org/jira/browse/FLEX-33386 Project: Apache Flex Issue Type: Improvement Components: Styles Reporter: RJ Camarillo Priority: Minor Labels: Performance, easyfix Fix For: Adobe Flex SDK Next Attachments: mx.styles - inlined.zip One of the most executed calls during the lifetime of a Flex UIComponent is the matching of style declarations (i.e. state change, component initialization, etc). As such, it is one that the community has monkey-patched often in order to attain speed-ups even for just a little. This is one of the improvements done to achieve that end. Instead of doing method calls to the different style classes (i.e. CSSCondition, CSSSelector, CSSStyleDeclaration), the StyleProtoChain class has been modified to perform matching inline as much as possible. The implementation is not perfect and I'm sure it can be improved further with the help of the bigger community. For example, the matchingDecls.sortOn(selectorIndex, Array.NUMERIC) call could be improve to use one of the faster sort algorithms out there. There are also some methods calls that are not inlined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33376) Missing locales in apache and experimental libs avoid its use in Maven
[ https://issues.apache.org/jira/browse/FLEX-33376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric THOMAS closed FLEX-33376. -- Missing locales in apache and experimental libs avoid its use in Maven -- Key: FLEX-33376 URL: https://issues.apache.org/jira/browse/FLEX-33376 Project: Apache Flex Issue Type: Bug Components: Internationalization Affects Versions: Apache Flex 4.9.0 Reporter: Frédéric THOMAS Assignee: Frédéric THOMAS Labels: bundle, locale, maven Fix For: Apache Flex 4.10.0 Most of the locales for the apache and experimental libs are not generated, this avoid any maven project using missing locales to compile if the project use the apache lib, common-framework.pom or the air-framework.pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33273) CSSCondition.matchesStyleClient() is slow and creates excessive garbage
[
https://issues.apache.org/jira/browse/FLEX-33273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frédéric THOMAS closed FLEX-33273.
--
CSSCondition.matchesStyleClient() is slow and creates excessive garbage
---
Key: FLEX-33273
URL: https://issues.apache.org/jira/browse/FLEX-33273
Project: Apache Flex
Issue Type: Improvement
Components: Styles
Affects Versions: Adobe Flex SDK 4.1 (Release), Adobe Flex SDK 4.5
(Release), Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release)
Reporter: Maurice Nicholson
Assignee: Frédéric THOMAS
Labels: patch, performance
Attachments: FLEX-33273.patch, mx.styles - inlined.zip,
PerformanceTest.zip
CSSCondition.matchesStyleClient() is called *very* frequently during layout
of components in many different scenarios.
I've done a lot of profiling of Flex apps and it comes up again and again.
The current implementation is slow and creates unnecessary garbage (which
slows down the runtime further, since it needs to collect the garbage instead
of doing more useful things).
Here is the current implementation:
{code}
public function matchesStyleClient(object:IAdvancedStyleClient):Boolean
{
var match:Boolean = false;
if (kind == CSSConditionKind.CLASS)
{
if (object.styleName != null object.styleName is String)
{
// Look for a match in a potential list of styleNames
var styleNames:Array = object.styleName.split(/\s+/);
for (var i:uint = 0; i styleNames.length; i++)
{
if (styleNames[i] == value)
{
match = true;
break;
}
}
}
}
else if (kind == CSSConditionKind.ID)
{
if (object.id == value)
match = true;
}
else if (kind == CSSConditionKind.PSEUDO)
{
if (object.matchesCSSState(value))
match = true;
}
return match;
}
{code}
Here is what I suggest instead:
{code}
public function matchesStyleClient(object:IAdvancedStyleClient):Boolean
{
var match:Boolean = false;
if (kind == CSSConditionKind.CLASS)
{
const styleName:String = object.styleName as String;
if (styleName)
{
// Look for a match in a potential list of styleNames
FIND:
{
var index:int = styleName.indexOf(value);
if (index == -1)
{
break FIND;
}
if (index != 0 styleName.charAt(index - 1) != ' ')
{
break FIND;
}
const next:int = index + value.length;
if (next != styleName.length styleName.charAt(next) !=
' ')
{
break FIND;
}
match = true;
}
}
}
else if (kind == CSSConditionKind.ID)
{
if (object.id == value)
match = true;
}
else if (kind == CSSConditionKind.PSEUDO)
{
if (object.matchesCSSState(value))
match = true;
}
return match;
}
{code}
There are obviously more concise ways to express this code, but the above
seems to match the current style more or less.
Here is the output from a benchmark I created using Grant Skinner's
PerformanceTest v2 Beta, comparing the current version and the suggested
version:
{noformat}
Comparing speed of matching a string in space delimited string. 100 loops.
Test Old ms New
ms Speedup Old mem New mem Change
matchesStyleClient(styleName: foo, value: foo)1006.00
181.00 -82.0 123.00 0.00 -100.0
matchesStyleClient(styleName: foo bar, value: foo)2107.00
206.80 -90.2 115.00 0.00 -100.0
matchesStyleClient(styleName: bar foo, value: foo)2099.80
232.30 -88.9 117.00 0.00 -100.0
matchesStyleClient(styleName: baz foo bar, value: foo)3193.80
251.30 -92.1 119.00 0.00 -100.0
matchesStyleClient(styleName: foobar, value: foo) 1169.50
192.00 -83.6 112.00 0.00 -100.0
matchesStyleClient(styleName: foofoo bar, value: foo) 2273.80
191.30 -91.6 116.00 0.00 -100.0
matchesStyleClient(styleName: fo, value: foo)
Re: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4)
Is it ok ? Can I process to a Vote ? -Fred -Message d'origine- From: Frédéric THOMAS Sent: Thursday, April 04, 2013 10:20 PM To: dev@flex.apache.org Subject: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4) Hi Justin, I Just checked in the updated version of the installer RC5 with the release builds for windows, could you build the Mac version please. Thanks, -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, April 01, 2013 9:00 AM To: dev@flex.apache.org Subject: Re: [DICUSS] Release InstallApacheFlex 2.5.3 - RC4 Ok, let's keep the same quality :) I go for a RC5, just the time for more testing though, I wouldn't like to do another RC after each typo issue. -Fred -Message d'origine- From: Alex Harui Sent: Monday, April 01, 2013 8:37 AM To: dev@flex.apache.org Subject: Re: [DICUSS] Release InstallApacheFlex 2.5.3 - RC4 On 3/31/13 11:16 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Some German typo only. Yeah, so you and Justin have to decide on whether to run another RC. How would you feel if there was a typo only in French? At Adobe we would not release with a known typo, but this isn't Adobe and isn't the main SDK. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Still confused by git
That's a good idea, I'm going to sit on the sideline too until at least PMCs want to learn the 10 basic commands and know how to use Git as describe, I just wonder how are going to react contributors and committers if even PMCs don't show the good example, well, to say the truth, I'm fed up, after 450 emails in March + 3 Wiki pages written to make the people understand and have a good workflow using Git and reading noone cars or wants to learn, I don't want to fight anymore and not even work on the SDK tree. Well, I already did my boxes closing the resolved JIRA, unassigned the others and committed my remote branch. I wish you a lot of pleasure. -Fred -Message d'origine- From: Nicholas Kwiatkowski Sent: Friday, April 05, 2013 2:11 PM To: dev@flex.apache.org Subject: Re: Still confused by git +1 on this. I've been sitting on the sidelines the last few weeks for that reason. I know there are a lot of standards that still need to be figured out, and since I'm very green with GIT, I don't really have the time at the moment to learn all the command line (i've been really busy with personal and professional stuff the last few weeks as well). My goal is not to use the command line, but use my IDE like I did before. Dropping to the command line and typing 10 commands every time I want to do something is a pain in the rear for those things that my IDE should be doing for me (I usually have a dozen command prompt windows open at any given time, but those are for truly interactive things). -Nick On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean jus...@classsoftware.comwrote: Hi, There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. I don't believe there is a consensus but that's mostly around how important it is to keep a clean history and with respect to Frederic obvious knowledge in this area we still need to come up with a way people new to git can contribute without knowing every intricate details of obscure options to git commands. In part because not everyone will use the command line. Thanks, Justin
RE: Still confused by git
Well the GUI's offer the same commands, they just have check boxes n such to select the different options of the command. I don't think it should matters if people learn the command line or GUI versions. Understanding what the commands do will happen more with practice. Reading the GIT online resources for the diagrams (example of one command [1]) helps to small degree. Should we setup a junk repo for people to play with the commands? (a shared one like on a GITHub repo). I know people could go out and setup their own. But I mean a structured one with populated content that gets reset to a known state weekly or after its been used. It could allow for practiced scenarios. [1] http://git-scm.com/book/en/Git-Branching-Rebasing -Mark -Original Message- From: Nicholas Kwiatkowski [mailto:nicho...@spoon.as] Sent: Friday, April 05, 2013 8:11 AM To: dev@flex.apache.org Subject: Re: Still confused by git +1 on this. I've been sitting on the sidelines the last few weeks for that reason. I know there are a lot of standards that still need to be figured out, and since I'm very green with GIT, I don't really have the time at the moment to learn all the command line (i've been really busy with personal and professional stuff the last few weeks as well). My goal is not to use the command line, but use my IDE like I did before. Dropping to the command line and typing 10 commands every time I want to do something is a pain in the rear for those things that my IDE should be doing for me (I usually have a dozen command prompt windows open at any given time, but those are for truly interactive things). -Nick
Re: Still confused by git
I'm sorry if I caused you to be fed up. I don't think it's that no-one cares or wants to learn. It's just that most of us have never used git before, and we have no clue what we're doing. It's a bit unnerving learning on such a big code base. I'm sure learning the basics of of git on a small project would be a lot easier… On Apr 5, 2013, at 4:01 PM, Frédéric THOMAS wrote: That's a good idea, I'm going to sit on the sideline too until at least PMCs want to learn the 10 basic commands and know how to use Git as describe, I just wonder how are going to react contributors and committers if even PMCs don't show the good example, well, to say the truth, I'm fed up, after 450 emails in March + 3 Wiki pages written to make the people understand and have a good workflow using Git and reading noone cars or wants to learn, I don't want to fight anymore and not even work on the SDK tree. Well, I already did my boxes closing the resolved JIRA, unassigned the others and committed my remote branch. I wish you a lot of pleasure. -Fred -Message d'origine- From: Nicholas Kwiatkowski Sent: Friday, April 05, 2013 2:11 PM To: dev@flex.apache.org Subject: Re: Still confused by git +1 on this. I've been sitting on the sidelines the last few weeks for that reason. I know there are a lot of standards that still need to be figured out, and since I'm very green with GIT, I don't really have the time at the moment to learn all the command line (i've been really busy with personal and professional stuff the last few weeks as well). My goal is not to use the command line, but use my IDE like I did before. Dropping to the command line and typing 10 commands every time I want to do something is a pain in the rear for those things that my IDE should be doing for me (I usually have a dozen command prompt windows open at any given time, but those are for truly interactive things). -Nick On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean jus...@classsoftware.comwrote: Hi, There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. I don't believe there is a consensus but that's mostly around how important it is to keep a clean history and with respect to Frederic obvious knowledge in this area we still need to come up with a way people new to git can contribute without knowing every intricate details of obscure options to git commands. In part because not everyone will use the command line. Thanks, Justin
Re: Still confused by git
That's not what I meant. It's in my plans to learn GIT, but I'm not going to be productive learning a new workflow with my 80+ hours of my FT job the last three weeks. My cheese was moved, and while I was trying to catch up the were still discussions about how to do things and what the standards were while I was trying to learn it. For me, the problem was the 450 emails over multiple threads that I couldn't keep up on. Personally I hate that everything relies on gitbash to do most commands under Windows. on my machine it's broken (hell, copy/paste only works half the time), so I'm always in the mode of trying to translate how to do X in an environment I'm not familiar with, on a complex project I could easily blow up, into something that at least lets me access my storage device where I'm supposed to be working. Nothing against you -- you've been helping out A LOT, but I'm just not up to speed yet. -Nick On Fri, Apr 5, 2013 at 9:01 AM, Frédéric THOMAS webdoubl...@hotmail.comwrote: That's a good idea, I'm going to sit on the sideline too until at least PMCs want to learn the 10 basic commands and know how to use Git as describe, I just wonder how are going to react contributors and committers if even PMCs don't show the good example, well, to say the truth, I'm fed up, after 450 emails in March + 3 Wiki pages written to make the people understand and have a good workflow using Git and reading noone cars or wants to learn, I don't want to fight anymore and not even work on the SDK tree. Well, I already did my boxes closing the resolved JIRA, unassigned the others and committed my remote branch. I wish you a lot of pleasure. -Fred -Message d'origine- From: Nicholas Kwiatkowski Sent: Friday, April 05, 2013 2:11 PM To: dev@flex.apache.org Subject: Re: Still confused by git +1 on this. I've been sitting on the sidelines the last few weeks for that reason. I know there are a lot of standards that still need to be figured out, and since I'm very green with GIT, I don't really have the time at the moment to learn all the command line (i've been really busy with personal and professional stuff the last few weeks as well). My goal is not to use the command line, but use my IDE like I did before. Dropping to the command line and typing 10 commands every time I want to do something is a pain in the rear for those things that my IDE should be doing for me (I usually have a dozen command prompt windows open at any given time, but those are for truly interactive things). -Nick On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean jus...@classsoftware.com** wrote: Hi, There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. I don't believe there is a consensus but that's mostly around how important it is to keep a clean history and with respect to Frederic obvious knowledge in this area we still need to come up with a way people new to git can contribute without knowing every intricate details of obscure options to git commands. In part because not everyone will use the command line. Thanks, Justin
Re: Still confused by git
In my quest to understand what's going on, maybe you can explain something to me. Most of your commits are flat in the graph, but a couple of them show as branches that are remerged. One example is FLEX-33451 Can you explain to me why that is? On Apr 5, 2013, at 4:01 PM, Frédéric THOMAS wrote: That's a good idea, I'm going to sit on the sideline too until at least PMCs want to learn the 10 basic commands and know how to use Git as describe, I just wonder how are going to react contributors and committers if even PMCs don't show the good example, well, to say the truth, I'm fed up, after 450 emails in March + 3 Wiki pages written to make the people understand and have a good workflow using Git and reading noone cars or wants to learn, I don't want to fight anymore and not even work on the SDK tree. Well, I already did my boxes closing the resolved JIRA, unassigned the others and committed my remote branch. I wish you a lot of pleasure. -Fred -Message d'origine- From: Nicholas Kwiatkowski Sent: Friday, April 05, 2013 2:11 PM To: dev@flex.apache.org Subject: Re: Still confused by git +1 on this. I've been sitting on the sidelines the last few weeks for that reason. I know there are a lot of standards that still need to be figured out, and since I'm very green with GIT, I don't really have the time at the moment to learn all the command line (i've been really busy with personal and professional stuff the last few weeks as well). My goal is not to use the command line, but use my IDE like I did before. Dropping to the command line and typing 10 commands every time I want to do something is a pain in the rear for those things that my IDE should be doing for me (I usually have a dozen command prompt windows open at any given time, but those are for truly interactive things). -Nick On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean jus...@classsoftware.comwrote: Hi, There's also been a lot of discussion on when to rebase and when not. I'm not clear on whether there has been a consensus on that. I don't believe there is a consensus but that's mostly around how important it is to keep a clean history and with respect to Frederic obvious knowledge in this area we still need to come up with a way people new to git can contribute without knowing every intricate details of obscure options to git commands. In part because not everyone will use the command line. Thanks, Justin
Website staging?
I'm adding my personal info to the about page. Is this supposed to be deployed to some staging are first, or does it get pushed out directly to the live site? Harbs
Re: Website staging?
Any changes you commit to SVN (don't ask ;-)) will be automatically pushed to the staging site by the 'buildbot'. You can view the staging area here: http://flex.staging.apache.org/ Once you're satisfied with the changes, you can promote them here: https://cms.apache.org/flex/publish HTH, EdB On Fri, Apr 5, 2013 at 8:35 AM, Harbs harbs.li...@gmail.com wrote: I'm adding my personal info to the about page. Is this supposed to be deployed to some staging are first, or does it get pushed out directly to the live site? Harbs -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Website staging?
Thanks. Very helpful. On Apr 5, 2013, at 4:47 PM, Erik de Bruin wrote: Any changes you commit to SVN (don't ask ;-)) will be automatically pushed to the staging site by the 'buildbot'. You can view the staging area here: http://flex.staging.apache.org/ Once you're satisfied with the changes, you can promote them here: https://cms.apache.org/flex/publish HTH, EdB On Fri, Apr 5, 2013 at 8:35 AM, Harbs harbs.li...@gmail.com wrote: I'm adding my personal info to the about page. Is this supposed to be deployed to some staging are first, or does it get pushed out directly to the live site? Harbs -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Website staging?
Information about the website, and how to update your about page profile is here : https://cwiki.apache.org/confluence/display/FLEX/Updating+your+profile+on+Team+page But yes, there is a staging server, and there is a script to push it to production. -Nick On Fri, Apr 5, 2013 at 9:35 AM, Harbs harbs.li...@gmail.com wrote: I'm adding my personal info to the about page. Is this supposed to be deployed to some staging are first, or does it get pushed out directly to the live site? Harbs
Re: Website staging?
I gotta remember to look at the wiki more… ;-) Thanks! On Apr 5, 2013, at 5:10 PM, Nicholas Kwiatkowski wrote: Information about the website, and how to update your about page profile is here : https://cwiki.apache.org/confluence/display/FLEX/Updating+your+profile+on+Team+page But yes, there is a staging server, and there is a script to push it to production. -Nick On Fri, Apr 5, 2013 at 9:35 AM, Harbs harbs.li...@gmail.com wrote: I'm adding my personal info to the about page. Is this supposed to be deployed to some staging are first, or does it get pushed out directly to the live site? Harbs
Re: Website staging?
One day we need to clean up the wiki. It's half really-old crap that should be purged (or updated), and half really useful stuff. The problem is that if you just glance at it, you see stale stuff and write it off. We should get better at that. -Nick On Fri, Apr 5, 2013 at 10:14 AM, Harbs harbs.li...@gmail.com wrote: I gotta remember to look at the wiki more… ;-) Thanks! On Apr 5, 2013, at 5:10 PM, Nicholas Kwiatkowski wrote: Information about the website, and how to update your about page profile is here : https://cwiki.apache.org/confluence/display/FLEX/Updating+your+profile+on+Team+page But yes, there is a staging server, and there is a script to push it to production. -Nick On Fri, Apr 5, 2013 at 9:35 AM, Harbs harbs.li...@gmail.com wrote: I'm adding my personal info to the about page. Is this supposed to be deployed to some staging are first, or does it get pushed out directly to the live site? Harbs
Re: [DISCUSS] How do we want to handle Whiteboard?
A lot of the people who currently have whiteboards have copies of the SDK in there... Would it still be possible to work on a private copy of the SDK in the whiteboard? The way I see it happening would be that you would fork the main SDK, and work on it in your own fork rather than the whiteboard... The other issue would be to bring the code back to the asf repo -- I could see that as problematic as well. -Nick On Fri, Apr 5, 2013 at 2:23 AM, Justin Mclean jus...@classsoftware.comwrote: Hi, Assuming we get the git hub mirrors up and working there nothing stopping anyone from using github to supply patches and diff in the usual way. A git hub pull request can be converted directly into a patch file and applied easily. There's one outstanding issue in how do we close pull requests, I asked this before but no one seem to know the answer. I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
On Thu, Apr 4, 2013 at 11:23 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, Assuming we get the git hub mirrors up and working there nothing stopping anyone from using github to supply patches and diff in the usual way. A git hub pull request can be converted directly into a patch file and applied easily. There's one outstanding issue in how do we close pull requests, I asked this before but no one seem to know the answer. I am confused, how is this related to the current topic under discussion? I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. GitHub keeps track of everything. Code that goes into the whiteboard is generally unstructured, experimental code. Only the committer decides when that goes into an official repo. This has to be done manually and the commit comments should have all the information about who contributed to this piece of code. Which means that we cannot bring the GitHub history with us as well. I dont see the need for that. If someone wants to see the history, they can always go to the relevant GitHub repo and look at it. Thanks, Om Thanks, Justin
Git needs a KISS
KISS = Keep It Simple, Stupid We've gotten ourselves in a hole where contributors are overwhelmed by the complexity of our recommended Git workflows and command lines. We need to dig ourselves out, and quickly, before we lose momentum. I don't think we should move back to Subversion, but I think we accept that many people would prefer a radically simpler approach to Git which is more like the one we were used to in Subversion. I think we made a serious mistake by pushing the nvie branching model (http://nvie.com/posts/a-successful-git-branching-model/) Just looking at the first diagram makes me want to close the page. This is overkill if all you're doing is fixing a bug or adding a test or something simple. The only part of nvie that should be mandatory is Don't' do any work on the 'master' branch. It should be fine for most contributors to check out the 'develop' branch and do all their work there. Most contributors shouldn't need to worry about using Git's stage or index. They can just commit all. You only need to stage things when you DON'T want to commit everything you've done. How often is that? We SHOULD NOT CARE if there are extra merge commits in the log. That's the way Git naturally works. Using obscure and controversial command line options to keep the log clean is not worth it, especially if it makes it harder for people to use visual Git clients. Many people, including me, do not enjoy working on the command line (although that's how I'm currently using Git). With a KISS approach, what most people need to know to use Git each day, after they've cloned the repo and checked out the develop branch, can be really simple: 1. Edit your files. No Git command required. 2. Merge in other people's work with 'git pull'. 3. If there a merge conflicts, fix them by editing. No Git command required. 4. See what files you've changed or added with 'git status'. 5. See what you've changed in a file with 'git diff file'. 6. Commit (to your local repo) what you've done with 'git commit -a'. 7. Share what you've done (in the public repo) with 'git push'. Note: There are only 7 steps. It's lore in cognitive science that people can remember 7 things but not necessarily more. Note: The only command-line option is -a to commit all your changes. All of these commands are probably available through any Git GUI. If you are working on a significant feature with a group of people over a period of time, then learning more about Git so that you can work together on a separate branch makes sense. But many contributors just want to make small changes, and the above workflow should suffice. If this KISS approach resonates, I'd like to have a poll on it. - Gordon
Re: Git needs a KISS
On Fri, Apr 5, 2013 at 10:27 AM, Gordon Smith gosm...@adobe.com wrote: KISS = Keep It Simple, Stupid We've gotten ourselves in a hole where contributors are overwhelmed by the complexity of our recommended Git workflows and command lines. We need to dig ourselves out, and quickly, before we lose momentum. I don't think we should move back to Subversion, but I think we accept that many people would prefer a radically simpler approach to Git which is more like the one we were used to in Subversion. I think we made a serious mistake by pushing the nvie branching model ( http://nvie.com/posts/a-successful-git-branching-model/) Just looking at the first diagram makes me want to close the page. This is overkill if all you're doing is fixing a bug or adding a test or something simple. The only part of nvie that should be mandatory is Don't' do any work on the 'master' branch. It should be fine for most contributors to check out the 'develop' branch and do all their work there. Most contributors shouldn't need to worry about using Git's stage or index. They can just commit all. You only need to stage things when you DON'T want to commit everything you've done. How often is that? We SHOULD NOT CARE if there are extra merge commits in the log. That's the way Git naturally works. Using obscure and controversial command line options to keep the log clean is not worth it, especially if it makes it harder for people to use visual Git clients. Many people, including me, do not enjoy working on the command line (although that's how I'm currently using Git). With a KISS approach, what most people need to know to use Git each day, after they've cloned the repo and checked out the develop branch, can be really simple: 1. Edit your files. No Git command required. 2. Merge in other people's work with 'git pull'. 3. If there a merge conflicts, fix them by editing. No Git command required. 4. See what files you've changed or added with 'git status'. 5. See what you've changed in a file with 'git diff file'. 6. Commit (to your local repo) what you've done with 'git commit -a'. 7. Share what you've done (in the public repo) with 'git push'. Note: There are only 7 steps. It's lore in cognitive science that people can remember 7 things but not necessarily more. Note: The only command-line option is -a to commit all your changes. All of these commands are probably available through any Git GUI. If you are working on a significant feature with a group of people over a period of time, then learning more about Git so that you can work together on a separate branch makes sense. But many contributors just want to make small changes, and the above workflow should suffice. If this KISS approach resonates, I'd like to have a poll on it. - Gordon +1 to everything you said :-) The key here is that there are people here with varying level of expertise with Git. Expecting a newbie to learn and understand the uber commands is not reasonable. Let us roll with the KISS strategy, let everyone get onboard with the Git philosophy. All the advanced commands can be learned as needed. Thanks, Om
Flex SDK Video access via CameraRoll/CameraUI local video access
I'm not certain how things stand with Apache incubating Flex and Adobe developing AIR. I'm wondering if this is something on the radar as far as the SDK development team goes, and if so, where it might stand, what we might expect. The below is specifically regarding iOS, but the non-existing API methods of course Specifically, the SDK lacks any way to - CameraRoll.browseForVideo() similar to CameraRoll.browseForImage() - Using the CameraUI to take a video creates a file in the system tmp that is not immediately available w/o first using FileIO to move it elsewhere. - Directly/simply accessing local video on the filesystem without involving a far more complex server/streaming model that is simply unnecessary (so far as I understand things) - Harvest frame BitmapData directly for display of thumbnails I've, personally had no luck with using Video or StageVideo to simply display a video file on the local file system that was -created/captured- using the delegated system level functionality. More directly stated... Native Video format doesn't seem to be playable on the device that created it (though this may just be my shortcomings as a developer). So... I can create videos using the delegated system camera util, but not play them. I can create videos outside of my software using the system camera which are then stored in the system CameraRoll, but I can in no ways use the existing native functionality to browse and select those videos in the way I can images. Is any of this being addressed? ANEs seem to be my only solution, but I've not found what I need so far and I've absolutely no time to dedicate to learning a new technology. Cheers. -- // Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri *And the wrens have returned, and are nesting;* *In the hollow of that oak, where his heart once had been.* *And he lifts up his arms in a blessing, for being born again.* Rich Mullins, The Color Green, A Liturgy, a Legacy, a Ragamuffin Band
RE: Git needs a KISS
I think we made a serious mistake by pushing the nvie branching model (http://nvie.com/posts/a-successful-git-branching-model/) First, we aren't using that branching model. Not even close. That model defines a viable workflow that we use successfully on many projects open and internal (5 to 500 people). What we have is a single git repo, and people who are new to git fighting over how to use the develop branch. I disagree with a lot of what you have said in the rest of your message honestly. However, I am not actively committing code and others are. I do think you can keep things simple. To be clear, there is a danger in what you mentioned, and it was what Fred was trying to address. So, let me mainly discuss that. 1. Edit your files. No Git command required. 2. Merge in other people's work with 'git pull'. 3. If there a merge conflicts, fix them by editing. No Git command required. 4. See what files you've changed or added with 'git status'. 5. See what you've changed in a file with 'git diff file'. 6. Commit (to your local repo) what you've done with 'git commit -a'. 7. Share what you've done (in the public repo) with 'git push'. Okay, at its heart, the danger Fred was worried about is that, using a merge workflow, the person who pulls the changes needs to make sure they commit all changes... even files they didn't touch, because they 'inherit' the merge. So, the thing that just needs to be made exceptionally clear on step 6 is that... even if they don't believe they touched the file they need to make sure it gets committed. For those new to git, if you are using this workflow, take a look at SmartGit. Its free to work on open source projects AND, mostly importantly, it would work find with the workflow you are proposing. It also handles merges well, which is going to be needed in this model. That my 2 cents. You can take this any way you want, I simply wanted to elucidate the one major danger that Fred was trying to fix. If users aren't careful in step 6, they end up committing a merge without someone elses change. Mike
Re: [jira] [Commented] (FLEX-33273) CSSCondition.matchesStyleClient() is slow and creates excessive garbage
Please remove me out of these emails.
I entered here by mistake.
Thanks,
Sujith
On Mon, Feb 4, 2013 at 8:07 PM, RJ Camarillo (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/FLEX-33273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570902#comment-13570902]
RJ Camarillo commented on FLEX-33273:
-
I don't see the changes for this in the trunk. Was it reverted?
CSSCondition.matchesStyleClient() is slow and creates excessive garbage
---
Key: FLEX-33273
URL: https://issues.apache.org/jira/browse/FLEX-33273
Project: Apache Flex
Issue Type: Improvement
Components: Styles
Affects Versions: Adobe Flex SDK 4.1 (Release), Adobe Flex SDK 4.5
(Release), Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release)
Reporter: Maurice Nicholson
Assignee: Frédéric THOMAS
Labels: patch, performance
Attachments: FLEX-33273.patch, PerformanceTest.zip
CSSCondition.matchesStyleClient() is called *very* frequently during
layout of components in many different scenarios.
I've done a lot of profiling of Flex apps and it comes up again and
again.
The current implementation is slow and creates unnecessary garbage
(which slows down the runtime further, since it needs to collect the
garbage instead of doing more useful things).
Here is the current implementation:
{code}
public function
matchesStyleClient(object:IAdvancedStyleClient):Boolean
{
var match:Boolean = false;
if (kind == CSSConditionKind.CLASS)
{
if (object.styleName != null object.styleName is String)
{
// Look for a match in a potential list of styleNames
var styleNames:Array = object.styleName.split(/\s+/);
for (var i:uint = 0; i styleNames.length; i++)
{
if (styleNames[i] == value)
{
match = true;
break;
}
}
}
}
else if (kind == CSSConditionKind.ID)
{
if (object.id == value)
match = true;
}
else if (kind == CSSConditionKind.PSEUDO)
{
if (object.matchesCSSState(value))
match = true;
}
return match;
}
{code}
Here is what I suggest instead:
{code}
public function
matchesStyleClient(object:IAdvancedStyleClient):Boolean
{
var match:Boolean = false;
if (kind == CSSConditionKind.CLASS)
{
const styleName:String = object.styleName as String;
if (styleName)
{
// Look for a match in a potential list of styleNames
FIND:
{
var index:int = styleName.indexOf(value);
if (index == -1)
{
break FIND;
}
if (index != 0 styleName.charAt(index - 1) != ' ')
{
break FIND;
}
const next:int = index + value.length;
if (next != styleName.length
styleName.charAt(next) != ' ')
{
break FIND;
}
match = true;
}
}
}
else if (kind == CSSConditionKind.ID)
{
if (object.id == value)
match = true;
}
else if (kind == CSSConditionKind.PSEUDO)
{
if (object.matchesCSSState(value))
match = true;
}
return match;
}
{code}
There are obviously more concise ways to express this code, but the
above seems to match the current style more or less.
Here is the output from a benchmark I created using Grant Skinner's
PerformanceTest v2 Beta, comparing the current version and the suggested
version:
{noformat}
Comparing speed of matching a string in space delimited string. 100
loops.
Test Old ms
New ms Speedup Old mem New mem Change
matchesStyleClient(styleName: foo, value: foo)1006.00
181.00 -82.0 123.00 0.00 -100.0
matchesStyleClient(styleName: foo bar, value: foo)2107.00
206.80 -90.2 115.00 0.00 -100.0
matchesStyleClient(styleName: bar foo, value: foo)2099.80
232.30 -88.9 117.00 0.00 -100.0
matchesStyleClient(styleName: baz foo bar, value: foo)3193.80
Re: [jira] [Commented] (FLEX-33273) CSSCondition.matchesStyleClient() is slow and creates excessive garbage
Send a blank email to dev-unsubscr...@flex.apache.org to unsubscribe from
the dev list.
Thanks,
Om
On Fri, Apr 5, 2013 at 11:57 AM, sujith Reddy sujith...@gmail.com wrote:
Please remove me out of these emails.
I entered here by mistake.
Thanks,
Sujith
On Mon, Feb 4, 2013 at 8:07 PM, RJ Camarillo (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/FLEX-33273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570902#comment-13570902
]
RJ Camarillo commented on FLEX-33273:
-
I don't see the changes for this in the trunk. Was it reverted?
CSSCondition.matchesStyleClient() is slow and creates excessive garbage
---
Key: FLEX-33273
URL: https://issues.apache.org/jira/browse/FLEX-33273
Project: Apache Flex
Issue Type: Improvement
Components: Styles
Affects Versions: Adobe Flex SDK 4.1 (Release), Adobe Flex SDK 4.5
(Release), Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release)
Reporter: Maurice Nicholson
Assignee: Frédéric THOMAS
Labels: patch, performance
Attachments: FLEX-33273.patch, PerformanceTest.zip
CSSCondition.matchesStyleClient() is called *very* frequently during
layout of components in many different scenarios.
I've done a lot of profiling of Flex apps and it comes up again and
again.
The current implementation is slow and creates unnecessary garbage
(which slows down the runtime further, since it needs to collect the
garbage instead of doing more useful things).
Here is the current implementation:
{code}
public function
matchesStyleClient(object:IAdvancedStyleClient):Boolean
{
var match:Boolean = false;
if (kind == CSSConditionKind.CLASS)
{
if (object.styleName != null object.styleName is String)
{
// Look for a match in a potential list of styleNames
var styleNames:Array = object.styleName.split(/\s+/);
for (var i:uint = 0; i styleNames.length; i++)
{
if (styleNames[i] == value)
{
match = true;
break;
}
}
}
}
else if (kind == CSSConditionKind.ID)
{
if (object.id == value)
match = true;
}
else if (kind == CSSConditionKind.PSEUDO)
{
if (object.matchesCSSState(value))
match = true;
}
return match;
}
{code}
Here is what I suggest instead:
{code}
public function
matchesStyleClient(object:IAdvancedStyleClient):Boolean
{
var match:Boolean = false;
if (kind == CSSConditionKind.CLASS)
{
const styleName:String = object.styleName as String;
if (styleName)
{
// Look for a match in a potential list of styleNames
FIND:
{
var index:int = styleName.indexOf(value);
if (index == -1)
{
break FIND;
}
if (index != 0 styleName.charAt(index - 1) != '
')
{
break FIND;
}
const next:int = index + value.length;
if (next != styleName.length
styleName.charAt(next) != ' ')
{
break FIND;
}
match = true;
}
}
}
else if (kind == CSSConditionKind.ID)
{
if (object.id == value)
match = true;
}
else if (kind == CSSConditionKind.PSEUDO)
{
if (object.matchesCSSState(value))
match = true;
}
return match;
}
{code}
There are obviously more concise ways to express this code, but the
above seems to match the current style more or less.
Here is the output from a benchmark I created using Grant Skinner's
PerformanceTest v2 Beta, comparing the current version and the suggested
version:
{noformat}
Comparing speed of matching a string in space delimited string. 100
loops.
Test Old ms
New ms Speedup Old mem New mem Change
matchesStyleClient(styleName: foo, value: foo)1006.00
181.00 -82.0
[jira] [Reopened] (FLEX-33451) The release build due to the Git migration is broken
[ https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Mclean reopened FLEX-33451: -- Assignee: (was: Frédéric THOMAS) Not completed yet. No need to open new issue better if it's keep all in issue. The release build due to the Git migration is broken Key: FLEX-33451 URL: https://issues.apache.org/jira/browse/FLEX-33451 Project: Apache Flex Issue Type: Bug Components: .Unspecified - Framework Affects Versions: Adobe Flex SDK Next Reporter: Frédéric THOMAS Priority: Critical Labels: Git, TLF, build, documentation The release build due to the Git migration is broken: - TLF external build - Build Number - ASDoc for the experimental lib - Building process (.gitignore, empty.properties) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (FLEX-33435) Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN
[ https://issues.apache.org/jira/browse/FLEX-33435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Mclean reopened FLEX-33435: -- Assignee: (was: Frédéric THOMAS) Documentation for making a release still not complete Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN - Key: FLEX-33435 URL: https://issues.apache.org/jira/browse/FLEX-33435 Project: Apache Flex Issue Type: Bug Components: Web Site Reporter: Justin Mclean Pages that need updating include: http://flex.apache.org/dev-faq.html http://flex.apache.org/dev-sourcecode.html http://flex.apache.org/download-source.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Git needs a KISS
Hi, Okay, at its heart, the danger Fred was worried about is that, using a merge workflow, the person who pulls the changes needs to make sure they commit all changes... even files they didn't touch, because they 'inherit' the merge. Do you have any advice on how to get around this issue in a simple way? I would of though that those changes would of already been in develop (99% of git pulls/git push are going to be from develop right?). Could this issue occur in the develop branch? If so is it easy to recognise that it has occurred and what would be the steps to fix it? For those new to git, if you are using this workflow, take a look at SmartGit. Thanks for the pointer will give it a go. Thanks, Justin
Re: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4)
Hi, Is it ok ? Can I process to a Vote ? Sorry having build issues - not sure if it git related or not. Once I'll sort out I'll put up unless someone beats me to it. Justin
Re: Still confused by git
Hi, after 450 emails in March + 3 Wiki pages written to make the people understand and have a good workflow using Git and reading noone cars or wants to learn I for one appreciated the effort and I have learnt a lot form it. It is a lot to take on and it's seemed to become very complex very quickly. I think a little patience all around is all that's needed. Thanks, Justin
Re: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4)
Hi, Is it ok ? Can I process to a Vote ? Good to go you can call fro a vote. Justin
Git remote branches
Hi, Just noticed this: git branch -r origin/FLEX-33451 origin/HEAD - origin/master origin/develop origin/master origin/patches origin/release4.9 ie : origin/FLEX-33451 is still a remote branch - should this be removed and if so what the safest way of doing that? If it is removed what happens to my local branch? Say I still had changes to commit - what then? git branch FLEX-33451 * develop master Thanks, Justin
Re: Git needs a KISS
For those new to git ... this is a nice read: http://tom.preston-werner.com/2009/05/19/the-git-parable.html Am 06.04.2013 01:06, schrieb Justin Mclean: Hi, Okay, at its heart, the danger Fred was worried about is that, using a merge workflow, the person who pulls the changes needs to make sure they commit all changes... even files they didn't touch, because they 'inherit' the merge. Do you have any advice on how to get around this issue in a simple way? I would of though that those changes would of already been in develop (99% of git pulls/git push are going to be from develop right?). Could this issue occur in the develop branch? If so is it easy to recognise that it has occurred and what would be the steps to fix it? For those new to git, if you are using this workflow, take a look at SmartGit. Thanks for the pointer will give it a go. Thanks, Justin -- _ FORMER 03 GmbH _ infanteriestraße 19 haus 6 _ 80797 muenchen _ robert.brend...@former03.de _ www.former03.de _ fon 089.322112.28 _ fax 089.322112.11 _ geschäftsführer _ sebastian fiedler _ gert zellentin _ handelsregister _ HRB München 148468 _ steuer _ ust.-id DE 229107876 _ TWITTER: http://twitter.com/FORMER03 _ FACEBOOK: http://www.facebook.com/former03 _ GOOGLE+: https://plus.google.com/109396067810508286409/posts _ YOUTUBE: http://www.youtube.com/former03gmbh
RE: Git needs a KISS
Okay, at its heart, the danger Fred was worried about is that, using a merge workflow, the person who pulls the changes needs to make sure they commit all changes... even files they didn't touch, because they 'inherit' the merge. Do you have any advice on how to get around this issue in a simple way? I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think). - Gordon -Original Message- From: Justin Mclean [mailto:jus...@classsoftware.com] Sent: Friday, April 05, 2013 4:07 PM To: dev@flex.apache.org Subject: Re: Git needs a KISS Hi, Okay, at its heart, the danger Fred was worried about is that, using a merge workflow, the person who pulls the changes needs to make sure they commit all changes... even files they didn't touch, because they 'inherit' the merge. Do you have any advice on how to get around this issue in a simple way? I would of though that those changes would of already been in develop (99% of git pulls/git push are going to be from develop right?). Could this issue occur in the develop branch? If so is it easy to recognise that it has occurred and what would be the steps to fix it? For those new to git, if you are using this workflow, take a look at SmartGit. Thanks for the pointer will give it a go. Thanks, Justin
[jira] [Assigned] (FLEX-33451) The release build due to the Git migration is broken
[ https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Mclean reassigned FLEX-33451: Assignee: Justin Mclean The release build due to the Git migration is broken Key: FLEX-33451 URL: https://issues.apache.org/jira/browse/FLEX-33451 Project: Apache Flex Issue Type: Bug Components: .Unspecified - Framework Affects Versions: Adobe Flex SDK Next Reporter: Frédéric THOMAS Assignee: Justin Mclean Priority: Critical Labels: Git, TLF, build, documentation The release build due to the Git migration is broken: - TLF external build - Build Number - ASDoc for the experimental lib - Building process (.gitignore, empty.properties) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Git needs a KISSa
Gordon and Justin, I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think). Unfortunately that won't prevent it. For now, it's more about just educating everyone about merges. Read this (and the comments if you are brave). [1] What Fred was advocating was a rebase workflow. What Gordon is proposing is mostly a merge workflow. That latter can work, we use it often, but it puts the onus on the developer doing the merge. Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches. The rest of the community happily worked from their own forks (which is basically just a server side copy of git all to your own) and just pulled in changes from develop, they didn't push to develop. That was the question I was originally asking Fred as to if there was a technical reason that we were setup this way. Incidentally, Fred did an excellent job on the wiki pages and making his case. I understand why everyone can see git as a pain right now. I really do. Ultimately the active committers on this list need to decide the correct route for the project. From my experience, this is the best analogy I can give. Please indulge me one last time. SVN was like a nail and everyone got good at using a hammer to put that nail into the wall. Git is a screw. When you start, it's natural to try to pound the screw into the wall the same way you did a nail. You can make it work, but it will seem cumbersome and inelegant compared to the ease of the nail. You won't see any advantages and it won't get any better, although you can make it work. If, however, you can begin to see that the screw works differently (and btw, that's the big thing git and SVN are honestly night and day in how they work and their workflow) and begin carrying the right tool, soon you can see that the screw has some advantages. It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy. There are growing pains, but they are not insurmountable. I personally wish we had more of a github fork model here where a couple of people have the keys to the castle. To be honest, that's what I was envisioning when I voted for git. It may not be possible at this point or ever, but the result is putting the onus on everyone learning more about git than they might otherwise need and having a miserable experience. So, read my link. Ask questions and I will answer here whenever possible. Mike [1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
Broken release build and git revision numbers
Hi, When we were using SVN the SVN revision number was used in various places. This needs to be a number (so hashes are out) and may need to be numerically increasing ie current number bigger than last number (not 100% on that). This effects: - Version numbers in framework XML description files. eg flex-config.xml. - Version.as files in the SDK. - Names of framework RSL files. For now I'm going to do this: tstamp format property=build.number.date pattern=MMdd / /tstamp ie set the build number to the current date. Can any Git experts please comment if there an alternative to doing this this way. Do any IDEs use the build number form the config is any way that may be broken by this approach? Can anyone see any issue (even minor) with this approach? This is a major change to how the SDK is builds, configures and names things so could have subtle and unknown side effects. Thanks, Justin
RE: Git remote branches
ie : origin/FLEX-33451 is still a remote branch - should this be removed and if so what the safest way of doing that? It can be removed although it won't hurt anything to hang around for a while. I honestly google the method to remove it most times: http://gitready.com/beginner/2009/02/02/push-and-delete-branches.html If it is removed what happens to my local branch? It won't affect your local branch. That will stay intact and viable. A branch isn't really a separate thing in git. All a branch really is at the end of the day is a text file that contains a unique identifier to the commit from which it started and a couple of text files describing the tree of the file system. So, those can exist locally or be pushed to the server but they are pretty much independent. Say I still had changes to commit - what then? Do you mean uncommitted local changes to that branch? If so, commit them :) Remember in git land you can commit every 30 seconds. I suspect you mean changes to merge in though and honestly that's fine. You can work on your local branch for as long as you want and then merge in when ready. If I am missing the point, just ask again Mike
RE: Broken release build and git revision numbers
Can any Git experts please comment if there an alternative to doing this this way. If you have a moment, take a look at git describe as an idea. It basically gives you the latest tag and a number of commits since then and a hash. Its not a simple sequence, but see if it helps. This one is okay. http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html Read Me: http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Generating-a-Build-Number
[VOTE] Release InstallApacheFlex 2.5.4 - RC5
*Issues addressed in this Release Candidate:* 1. Enable Flex SDK download stats tracking 2. https://issues.apache.org/jira/browse/FLEX-33426 (UI fix for license screen (show regular checkboxes)) 3. https://issues.apache.org/jira/browse/FLEX-33151 (Auto-update logic fix) 4. French and Dutch language locale fixes. 5. Added the SDK version number to be downloaded in the window title. 6. https://issues.apache.org/jira/browse/FLEX-33202 (more issues). 7. https://issues.apache.org/jira/browse/FLEX-33419 (added germain language). This is the first official release of the InstallApacheFlex AIR application. The official Apache distribution is the source kit which can contain only source. The source distributions for Windows and Mac are available here: https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/sources/ The binary distributions as a convenience for the respective platforms, available here: https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/binaries/ Along with the installer, we are releasing the 'badge installer' that can be embedded in our site as well as third-party websites. Here is a preview: http://flex.apache.org/installer.html *Before voting please review the section,* What are the ASF requirements on approving a release? at http://www.apache.org/dev/release.html#approving-a-release *Please vote to approve this release:* [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for at least 72 hours. Regards, Om Justin Fred Apache Flex PMC members + Release managers
Re: Git remote branches
Hi, It won't affect your local branch. That will stay intact and viable. Even when it tracking the remote branch? I suspect you mean changes to merge Yep. However the remote branch has already been merged into develop (which I may or may not know depend on how close attention I've been paying to the commit log) - seems like potential for confusion on which version is the correct one here. Thanks, Justin
Re: Git needs a KISSa
Hi, Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches. Could that work for us? (With committers pushing to develop that is?) Could someone who a git expert clean up the log on develop from time to time as required? Would anyone want to do that? It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy. I don't think that the issue. Most of us know some git and get what the benefits are (local branches, offline commits etc etc). I used git successfully on other projects and on my own projects and it was not this complex and there were minimal issues. I personally wish we had more of a github fork model here where a couple of people have the keys to the castle. Which is probably against the Apache Way. [1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/ And this is the problem I run into again and agin when reading about git. if you read the conclusion to me it's saying you need to be really really careful using rebase. It seems to me having a slightly messy log is the lesser evil. Thanks, Justin
Re: [VOTE] Release InstallApacheFlex 2.5.4 - RC5
+1 Used binary distro on Windows (7/64) + MacOS (10.8.3/64). All in English. Worked just fine. MD5 Hash matches. Good job guys! -Nick On Fri, Apr 5, 2013 at 9:35 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: *Issues addressed in this Release Candidate:* 1. Enable Flex SDK download stats tracking 2. https://issues.apache.org/**jira/browse/FLEX-33426https://issues.apache.org/jira/browse/FLEX-33426(UI fix for license screen (show regular checkboxes)) 3. https://issues.apache.org/**jira/browse/FLEX-33151https://issues.apache.org/jira/browse/FLEX-33151(Auto-update logic fix) 4. French and Dutch language locale fixes. 5. Added the SDK version number to be downloaded in the window title. 6. https://issues.apache.org/**jira/browse/FLEX-33202https://issues.apache.org/jira/browse/FLEX-33202(more issues). 7. https://issues.apache.org/**jira/browse/FLEX-33419https://issues.apache.org/jira/browse/FLEX-33419(added germain language). This is the first official release of the InstallApacheFlex AIR application. The official Apache distribution is the source kit which can contain only source. The source distributions for Windows and Mac are available here: https://dist.apache.org/repos/**dist/dev/flex/installer/2.5/**RC5/sources/https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/sources/ The binary distributions as a convenience for the respective platforms, available here: https://dist.apache.org/repos/**dist/dev/flex/installer/2.5/** RC5/binaries/https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/binaries/ Along with the installer, we are releasing the 'badge installer' that can be embedded in our site as well as third-party websites. Here is a preview: http://flex.apache.org/**installer.htmlhttp://flex.apache.org/installer.html *Before voting please review the section,* What are the ASF requirements on approving a release? at http://www.apache.org/dev/**release.html#approving-a-**releasehttp://www.apache.org/dev/release.html#approving-a-release *Please vote to approve this release:* [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for at least 72 hours. Regards, Om Justin Fred Apache Flex PMC members + Release managers
Re: Git needs a KISSa
Unfortunately that won't prevent it. Please explain why not. - Gordon Sent from my iPad On Apr 5, 2013, at 6:21 PM, Michael A. Labriola labri...@digitalprimates.net wrote: Gordon and Justin, I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think). Unfortunately that won't prevent it. For now, it's more about just educating everyone about merges. Read this (and the comments if you are brave). [1] What Fred was advocating was a rebase workflow. What Gordon is proposing is mostly a merge workflow. That latter can work, we use it often, but it puts the onus on the developer doing the merge. Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches. The rest of the community happily worked from their own forks (which is basically just a server side copy of git all to your own) and just pulled in changes from develop, they didn't push to develop. That was the question I was originally asking Fred as to if there was a technical reason that we were setup this way. Incidentally, Fred did an excellent job on the wiki pages and making his case. I understand why everyone can see git as a pain right now. I really do. Ultimately the active committers on this list need to decide the correct route for the project. From my experience, this is the best analogy I can give. Please indulge me one last time. SVN was like a nail and everyone got good at using a hammer to put that nail into the wall. Git is a screw. When you start, it's natural to try to pound the screw into the wall the same way you did a nail. You can make it work, but it will seem cumbersome and inelegant compared to the ease of the nail. You won't see any advantages and it won't get any better, although you can make it work. If, however, you can begin to see that the screw works differently (and btw, that's the big thing git and SVN are honestly night and day in how they work and their workflow) and begin carrying the right tool, soon you can see that the screw has some advantages. It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy. There are growing pains, but they are not insurmountable. I personally wish we had more of a github fork model here where a couple of people have the keys to the castle. To be honest, that's what I was envisioning when I voted for git. It may not be possible at this point or ever, but the result is putting the onus on everyone learning more about git than they might otherwise need and having a miserable experience. So, read my link. Ask questions and I will answer here whenever possible. Mike [1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
Re: Git needs a KISSa
Your link says Merge is perfectly fine for managing your code. The only drawback it mentions is a more cluttered log. It has far stronger warnings about misusing rebase. How could anyone read this conclusion 1. Merge works great, but creates lots of empty merge commits when you are working on a team. 2. Rebase keeps things tidy, but is destructive and potentially dangerous if you don’t know what you are doing. and not conclude that merge is better for non-experts? - Gordon Sent from my iPad On Apr 5, 2013, at 7:12 PM, Gordon Smith gosm...@adobe.commailto:gosm...@adobe.com wrote: Unfortunately that won't prevent it. Please explain why not. - Gordon Sent from my iPad On Apr 5, 2013, at 6:21 PM, Michael A. Labriola labri...@digitalprimates.netmailto:labri...@digitalprimates.net wrote: Gordon and Justin, I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think). Unfortunately that won't prevent it. For now, it's more about just educating everyone about merges. Read this (and the comments if you are brave). [1] What Fred was advocating was a rebase workflow. What Gordon is proposing is mostly a merge workflow. That latter can work, we use it often, but it puts the onus on the developer doing the merge. Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches. The rest of the community happily worked from their own forks (which is basically just a server side copy of git all to your own) and just pulled in changes from develop, they didn't push to develop. That was the question I was originally asking Fred as to if there was a technical reason that we were setup this way. Incidentally, Fred did an excellent job on the wiki pages and making his case. I understand why everyone can see git as a pain right now. I really do. Ultimately the active committers on this list need to decide the correct route for the project. From my experience, this is the best analogy I can give. Please indulge me one last time. SVN was like a nail and everyone got good at using a hammer to put that nail into the wall. Git is a screw. When you start, it's natural to try to pound the screw into the wall the same way you did a nail. You can make it work, but it will seem cumbersome and inelegant compared to the ease of the nail. You won't see any advantages and it won't get any better, although you can make it work. If, however, you can begin to see that the screw works differently (and btw, that's the big thing git and SVN are honestly night and day in how they work and their workflow) and begin carrying the right tool, soon you can see that the screw has some advantages. It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy. There are growing pains, but they are not insurmountable. I personally wish we had more of a github fork model here where a couple of people have the keys to the castle. To be honest, that's what I was envisioning when I voted for git. It may not be possible at this point or ever, but the result is putting the onus on everyone learning more about git than they might otherwise need and having a miserable experience. So, read my link. Ask questions and I will answer here whenever possible. Mike [1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
Git release instructions
Hi, Can someone with more git experience than me please update the instructions here: https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK It sort of important that we make how to make a release. :-) I'm marked with FIXME where changes need to be made. Thanks, Justin
Re: Broken release build and git revision numbers
HI, The one minor down side is that it's now it harder to tell exactly where a SDK was build from (no revision number n flex-describtion.xml). There would be a branch with the same version number so it's a minor annoyance. Justin
Re: [VOTE] Release InstallApacheFlex 2.5.4 - RC5
+1 Successfully installed installer and flex on Windows 7 (64bit) - Language German Thank you! Cyrill On Sat, Apr 6, 2013 at 12:35 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: *Issues addressed in this Release Candidate:* 1. Enable Flex SDK download stats tracking 2. https://issues.apache.org/jira/browse/FLEX-33426 (UI fix for license screen (show regular checkboxes)) 3. https://issues.apache.org/jira/browse/FLEX-33151 (Auto-update logic fix) 4. French and Dutch language locale fixes. 5. Added the SDK version number to be downloaded in the window title. 6. https://issues.apache.org/jira/browse/FLEX-33202 (more issues). 7. https://issues.apache.org/jira/browse/FLEX-33419 (added germain language). This is the first official release of the InstallApacheFlex AIR application. The official Apache distribution is the source kit which can contain only source. The source distributions for Windows and Mac are available here: https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/sources/ The binary distributions as a convenience for the respective platforms, available here: https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/binaries/ Along with the installer, we are releasing the 'badge installer' that can be embedded in our site as well as third-party websites. Here is a preview: http://flex.apache.org/installer.html *Before voting please review the section,* What are the ASF requirements on approving a release? at http://www.apache.org/dev/release.html#approving-a-release *Please vote to approve this release:* [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for at least 72 hours. Regards, Om Justin Fred Apache Flex PMC members + Release managers
AIR 3.7 support for Apache Flex
Hi, Just a heads up/prgress on AIR 3.7 support from Adobe: Our official 3.7 release is scheduled for next week (if all goes as planned.) If you can hang on that long we'll have a build that you'll be able to simply overlay as you would normally expect. We are working to improve/correct this situation and include both SDK releases in our upcoming AIR 3.8 betas. Thanks, Justin 1.http://forums.adobe.com/message/5171561#5171561
[jira] [Commented] (FLEX-33451) The release build due to the Git migration is broken
[ https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13624325#comment-13624325 ] Justin Mclean commented on FLEX-33451: -- ant release now works but need more testing. Ant in the asdoc directory fails and I have no idea how to fix. This stops up creating asdocs to include in the release. Can someone take a look at this? The release build due to the Git migration is broken Key: FLEX-33451 URL: https://issues.apache.org/jira/browse/FLEX-33451 Project: Apache Flex Issue Type: Bug Components: .Unspecified - Framework Affects Versions: Adobe Flex SDK Next Reporter: Frédéric THOMAS Assignee: Justin Mclean Priority: Critical Labels: Git, TLF, build, documentation The release build due to the Git migration is broken: - TLF external build - Build Number - ASDoc for the experimental lib - Building process (.gitignore, empty.properties) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FLEX-33451) The release build due to the Git migration is broken
[ https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Mclean reassigned FLEX-33451: Assignee: (was: Justin Mclean) The release build due to the Git migration is broken Key: FLEX-33451 URL: https://issues.apache.org/jira/browse/FLEX-33451 Project: Apache Flex Issue Type: Bug Components: .Unspecified - Framework Affects Versions: Adobe Flex SDK Next Reporter: Frédéric THOMAS Priority: Critical Labels: Git, TLF, build, documentation The release build due to the Git migration is broken: - TLF external build - Build Number - ASDoc for the experimental lib - Building process (.gitignore, empty.properties) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Apache Flex oustanding bugs
Hi, There are currently: 1 unassigned unresolved blocker bugs 20 unassigned unresolved critical bugs 2901 unassigned unresolved major bugs It may be that some of these have already been fixed, should not be at priority etc etc but I'd assume most of them are outstanding. Are there any developer or committer with a little spare time about to put in some effort to help reduce this number? I can't see us making a release while we are in this state which is what we should be trying to do on a regular basis. We need to be supporting current users of the SDK. Justin
Re: Apache Flex oustanding bugs
On 4/6/2013 10:09 AM, Justin Mclean wrote: Hi, There are currently: 1 unassigned unresolved blocker bugs 20 unassigned unresolved critical bugs 2901 unassigned unresolved major bugs It may be that some of these have already been fixed, should not be at priority etc etc but I'd assume most of them are outstanding. Are there any developer or committer with a little spare time about to put in some effort to help reduce this number? I can't see us making a release while we are in this state which is what we should be trying to do on a regular basis. We need to be supporting current users of the SDK. Justin +1 I agree
Welcome our newest Apache Flex committer Harbs
Hi, The Project Management Committee (PMC) for Apache Flex has asked Harbs to become a committer and we are pleased to announce that he has accepted. Harbs has been contributing to Apache Flex for many months on the mailing list and in JIRA and elsewhere including this blog post a few months back. http://printui.com/blog/2013/01/flex-flash/ He's just checked in an improved version of the spark colour picker. Congratulations Justin Mclean for the Flex PMC
