Submitting a patch to the Flex SDK

Submitted by Falken on Thu, 01/29/2009 - 12:33

As I [node:1559, title="mentioned yesterday"] submitting a patch to fix a problem with the Flex SDK is a great way to get to know the framework itself better, and also see how the process works.

There isn't much too it, esp. if you are fixing a bug you found.

First off, you need (just once) to sign an agreement that says you did the work, you donate it to the project, and you are allowed to donate it. This is fairly standard stuff in open source projects, and covers the common case where your employer owns everything you write while in work and may not want their hard work to be given away.
See the link at the end of this article for details about that process, but I was able to sign it and just email the scan back - this process was very quick.

While you wait for that to happen (and if this is your second patch, start here :-) ), make sure you log the bug against the SDK project. You might also want to post to FlexCoders etc. to see if anyone else knows of the problem or a way to fix it.

Once you've decided you want to tackle fixing the issue, grab the latest SDK and double check your test case (you did write one, right ? And attach it to the bug report ? If not, go back and do it :-) ).

Now the hard part - fire up your development tools, and hack away at the code and fix the problem. Make sure you are using the latest SDK as above (at the moment, that could be Flex 3.x or Flex 4 nightly).

Once you've fixed it, generate a patch (as a 'diff' file) and click 'submit patch' on the issue in the bug database. If you don't have that link, see step 1 above :-)  You could attach the changed files, but a patch makes it clearer what was changed.
Enter all the details asked for and press the button.

You might want to double check that your patch applies against the latest version of the SDK by checking the SDK out from SVN, applying your patch and then doing your tests again, followed by the check-in tests.
For small bug fixes this is normally overkill, but if you take the time to learn it it will pay off if you ever do something bigger.

Now sit back and wait - the patch will be reviewed by Adobe, and all being well, you'll see it gets committed into the code base - go you :-)

The above is based on my experience of 2 (two !) submissions (both now accepted) : #SDK-18000 and #SDK-14767.
You can see the second one didn't quite follow the process, but it worked out OK in the end- so don't worry too much, get patching.

Full details are on, or ask on Adobe's SDK forum.