+1 to Ian's comments. How about if: - the developer (contributor or committer) is responsible to test their own code and correct any problems before a pull request is submitted (contributor authored) or it lands in the stream (committer authored). The testing includes both verifying the function they added/touched, plus running mobile-spec to verify there are no regressions. - if a pull request, the committer should sanity check the contributor's code. - if a pull request, the committer should see that the contributor tested it. Perhaps that could be a simple comment in Jira, similar to how Mike and Lisa worked as contributors here: https://issues.apache.org/jira/browse/CB-3521 .
I find it odd that "Processing Pull Requests" in http://wiki.apache.org/cordova/CommitterWorkflow doesn't mention anything about testing or sanity checking / reviewing what comes from the contributor. If there is consensus, I can add the verbage above to "Processing Pull Requests". (Hmm, shouldn't there also be something there about doc for external behaviors / interfaces / requirements?) Based on other commercial projects I've seen, and how aggressive you want to be, I'd also be tempted to suggest: - every new function and defect fix should include an automated test (where reasonably feasible) that lands in mobile-spec at the same time as the new function / fix. What this does over time is to build up coverage in the automated test suite that gets a lot better at catching breakages / regressions. Yes, this takes time to do, but when mobile-spec is run, you've got confidence. -- Marcel Kinard
