On 9/4/13 3:39 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>HI, > >> At Adobe, if new failures appeared and it was in tests that could have >> been affected by code you changed, you had to revert or fix immediately. > >We are not at Adobe, other committers should be willing to help out on >bug fixing and testing in a collaborative way. We want to encourage >people to put forward or commit fixes, not scare them away with if all >tests don't pass you have to revert. I don't want to add the extra burden >on people of having to run ALL of the mustella tests before submitting a >fix, let the CI system do that for them. I'm willing to help out, but it helps if you have done some basic research on any test failures in code you may have changed. If you write to the list and say that you locally reverted change X and it made the failures go away and you debugged into the test but got stuck, I'll be more willing to take a look because you've narrowed down which changes are in play. But from experience if changes get stacked on a bad change, it can make reverting harder and makes folks not trust the CI system. That's why I've invested my time on other mustella tools. If you compile every test, then run MustellaDependencyDB, it will create a database of dependencies such that, if you run MustellaTestChooser, it will generate a list of tests that need to be run based on the changed files so you don't have to run ALL of the tests. Going further, I put in a shell script called run_mustella_on_git_status.sh. Assuming you have MustellaTestChooser already built, it will call git status, run the output through MustellaTestChooser and run the required tests all while you sleep or eat or poop or some combination of the above. Tip: Wait for it to start dumping the list of tests to run so you get an idea how long you should go away. And I've also put together a Patch Testing Server so you can get some other computer to run the minimal set of tests before checking in. The goal is to reduce the chances a check in will break the full CI run. > >> If so, Justin, can you revert some of your recent checkins in those >>areas? >Sorry but I'm not going to revert a checkin that actually fixes a bug and >when is it most likely that the test is now not working. If the fix had >introduced an obvious error then yes reverting or changing the fix would >be the way to go. We have a trunk and a develop branch, the whole point >of the develop branch is for it to be a work in progress. > >As I said before the DG test is failing due to a correct out of range >RTE, the test needs changing, has anyone actually looked at the test? I haven't. I'm still hoping you will at least locally revert some of your changes to see if they are in fact related to these failures, and at least make an attempt to debug the tests so it will be more efficient for me to help. Otherwise, folks can just check in what they want and rely on others to prove them wrong or fix up any repercussions, and that doesn't feel like good community membership to me. > >> I use FDB, but there is supposedly a way to launch a SWF in the FB >> debugger without having to build a process around it. >I've never been able to get either to work on OSX/my environment. OK, let's start there. I'm using FDB on OSX. What happens when you try to launch the SWF? Use "fdb pathtoswf" -Alex
