On 11/05/2014 05:31 PM, Nick Daly wrote: > Hi folks, I've recently had a few questions about the FBX community's merge > policy, and wanted to bring them to the list, because it might be helpful > to have a well documented standard available on the wiki. > > I would like to hold myself to something like the following: > > - Unit tests pass. > - Style tests (pep8.py, etc.) pass. > > This at least makes sure that code hasn't become broken and that it looks > similar to other code already in the project. This isn't something I've > enforced (FreedomBuddy doesn't *have* any tests other than acceptance > tests), but something I'd like to start sticking to, in order to set clear > expectations for patchers. > > What other criteria do other folks use? > > Thanks, > Nick
A few immediate thoughts: 1. A clean build, including no failing tests, would want to be a basic criterion for all routine commits. However, for all the coverage and analysis metrics that I hope to have implemented sooner than later, I'd be comfortable simply with having initial, sub-100% minimum thresholds established that we could incrementally raise over time, just so that we don't impose on ourselves the obligation of being fully conformant right out of the starting gate. For instance, per the test coverage analysis that I'm in the process of hosing up at the moment, total coverage for the entire project stands at %3 (since there's currently just one test module for actions.py). So maybe we set the initial minimum coverage threshold for the next release at 10%, to give ourselves a reasonable, attainable target, and then go in modest increments from there. We also want minimum thresholds so that all new code continues to match the current standards for coverage and analysis, rather than pulling the conformance numbers down. 2. Travis CI <https://travis-ci.org/> might be a big help in catching integration or code inspection issues that might have been missed at the local repository level. 3. For perhaps release candidates only, Cheesecake <http://pycheesecake.org/> might make an effective automated gating component to the merge policy, as it includes evaluation of not just the code (presence of tests, pep8, and pylint), but of the entire package (installability, documentation, etc.). _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
