[Freedombox-discuss] Merge Policy?

[Anders Jackson]

2014-11-06 20:17 GMT+01:00 Bob Girard <bgirard at esedona.net>:
>
> 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

Unit testing and some other testings, like how well packages follows
Debian standards for installing and removing should of course be
addopted.

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

Reasonable targets are good targets.  I think this is reasonable
targets.  It is also important to get some experiance and some good
examples that can be docummented and others to follow.

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

Integration tests are not done in Debian test infrastructure, what I
know of.  But there are infrastructure for checking the quality of
package and how well they install and uninstall.  So those package can
be constantly checked in Debian now.

But for integration tests of packages for freedombox and other tests
that isn't Unit tests, Debian has to be checked to see if there are
som projects working on that.  There might be something like this in
the pipeline.

Those tools you mentioned need to be packed in Debian before we should
use them.  Because if they are, it would be easier to make it work for
FreedomBox and it might work as an new quality infra structure for
Debian too.

/Jackson