Because contribution is on a volunteer basis, we can't assign certain types of bugs to individuals, and we have to have a scheme that allows for some level of coordination across the globe so we don't waste too much time duplicating effort. Below is a rough idea of the things you should do when you want to fix an Apache Flex bug.
Setup
1. Build SDK from Git source
Before you start, you must get the Flex SDK source code to compile and run from Git. You are welcome to use the InstallApacheFlex installer to get the SDK to build your applications, but for changing the SDK source code, it is best to get the source code from Git. Please use the develop branch at: https://git-wip-us.apache.org/repos/asf/flex-sdk.git. Read the README file at the base of the develop branch for the set of environment variables and pre-requisite downloads you will need to get the build script to work.
2. Run Mustella
We currently use the Mustella test suite to validate changes to the SDK. See the mustella overview here . If you have followed setup 1 and can build the source from SVN, then running mustella should be as simple as changing to the mustella folder and running mini_run.sh as described in the overview. In theory, all the defaults should be set to work. There are 35000 tests at this time, and running them all takes some 8 hours on some computers. It is recommended that you run "./mini_run.sh -all" in order to make sure every test passes for you so you know you have everything configured correctly. If you are in a real hurry, you can skip running all of the tests, but you should take the two or three hours to compile all of the tests that "./mini_run.sh -all" will compile so it will generate the link-reports used by some of the Mustella utilities to pick out which of the 35000 tests you will need to run to validate your changes. This is a good thing to do overnight or before going out for the evening.
3. Build Mustella Utilities
Mustella tests tend to pull in lots of code from other places in the framework. While running the Button tests because you changed Button.as will give you a good idea of you broke anything, a significant portion of other tests outside the Button folder use Button since it is involved in scrollbars and form tests and what not, so in just running the Button folder of tests, there is a minimal chance you will miss something, but we've seen it happen. So, please follow the instructions in the Mustella Overview to build those utilities. They run relatively quickly (minutes, not hours) so after building MustellaDependencyDB, it is a good idea to run it.
Fixing A Bug
Once you are setup, you should be able to use the following steps over and over again when fixing bugs.
4. Pick A Bug
Pick a bug and use JIRA to assign it to yourself. If you get busy or decide it is too hard for the amount of time you have, please unassign yourself from the bug. If you are not a committer you won't be able to assign the bug, so please leave a comment that you are working on it. If you are looking for bugs to fix, we will try to mark bugs that nobody is working on that we think are easy to fix with the label "EasyFix". Here is a link to the list of such bugs: EasyFix Bugs
5. Run Bug Test Case
Bugs should have a simple test case. If they don't, we support you asking the bug author for one, but if you are feeling generous, you can take the time to provide one. There are so many bugs that there could be duplicates without us knowing it, and someone may have already fixed this bug under a different issue number, so if the bug doesn't replicate, you might want to check the SVN log to see if someone fixed a bug like this already, or mark it as "cannot reproduce".
6. Fix The Bug
The most common mistake we see in bug fixing is fixing the one test case and not considering other cases. Don't forget the standard rules of development (localization, accessibility, performance). For performance, we have generally used a "Garbage-In/Garbage-Out" rule meaning that we don't validate input parameters, but it is ok to do so if there is no additional cost. There is much debate about whether "minimal" costs are worth it. Eventually they can all add up, so be prudent.
7. Validate The Fix
Once the test case passes with your changes, it is time to see if you broke anything else. In theory, you can execute the following (from the sdk directory (and stop and go back if you get failures):
- ant main checkintests
- git status -s | grep "^[ M]"
- copy results to clipboard
- MustellaTestChooser (from wherever you installed it)
- cd mustella
- ./mini_run.sh -changes
The last command will run all of the tests found by MustellaTestChooser. If you changed something fundamental, this can take hours to run.
8. Commit Changes
Please add the bug # to the checkin notes. If you are not a committer, you will have to attach a patch for your changes to the JIRA issue and email the dev@flex.apache.org list to try to get someone to commit your patch.
8. Resolve Bug in JIRA
Please add the SVN revision number to the comments. Some folks think that bugs should not be "closed" until the develop branch is merged into the trunk branch. Some folks are closing bugs right after resolving them. Still others think bugs should not be closed until independently verified by someone else. Someday we will decide on this issue.
9. Add Mustella Tests (Optional)
In theory, you should add additional Mustella tests since the fact there is a bug indicates a lack of a test for that scenario.
Thank you for contributing to Apache Flex!