[email protected] wrote on 11/21/12 9:28 AM: > 1. Any work Henrik already started for certain crashtests (since I > know he's got a few in queue) - finish those off
The primarily work I wanted to do here is done now. I have investigated our two blockers which prevents us from turning on crashtests on mozilla-central. Those are now in developers hands. That means today I will get some of the crashtests written for still broken cases. I will not spend more than half a day on it. > 2. Henrik shifts focus towards smoke test automation for the full > stack, I'll finish off the gUM smoke test automation (which is 90% > done). To combine what everyone else said, what do you want me to start on first? Are these gUM or PeerConnection tests? I think with Jasons basic gUM tests we have a good first start once landed, and I should do a similar thing for the peerconnection piece. > 3. We establish a review policy that any patches that can definitely > have a crashtest associated with them has to be included on check-in > by the developer building the patch. If the patch comes in without a > crashtest that can indeed possibly have one, the patch gets a review- > until the test is included. That will balance both validating that > the patch actually does work at check-in, but also starts to burn > through progressively building out a crashtest regression automation > suite. I would love that because of: * it helps devs to check that the crash has been fixed across platforms by pushing it to try (via the alder branch for now) instead of only testing it on their own platform work happens. * crashtests are easy to create from the already attached testcases. > Does that work? I do understand the concerns Ekr and Randell raise, > but I also don't want to take risks on crash regressions too much > given the high crash bug rate, even with the feature currently prefed > off. That's my concern too and I will see soon what has been changed for basic PeerConnection tests since I tried it the last time. -- Henrik _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
