[Freedombox-discuss] Merge Policy?

[Bob Girard]

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.).