On 02/05/2014 12:07 PM, Lucas Meneghel Rodrigues wrote: > (3) - Somehow come up with 'rules' about what belongs to test providers > -virttest -autotest. > (4) - Have API police ready to enforce the rules.
Suggestions: Perhaps ignore the module level at first. It's an organization layer developed within a different context then we're after here. The heart of the matter really is what functions and classes are there, what are their relationships, and where should they go based on their current purpose and relationships. So: 3a) Classes/Functions which are clearly serving all test-providers belong in the core. That does not include items which have _potential_ or _intended_ future uses, only actual and current. 3b) Classes/Functions which are less-clear, out-of-place, or only marginally serve one TP while substantially serving another should be "adjusted" to fit #3a. i.e. move/duplicate the minority use-case elsewhere, fold it up the dependency tree into it's caller(s), etc. 4a) Anyone doing code-review needs to keep an eye out for #3, especially for additions to the core code. It's _MUCH_ easier to move code from a TP into core (due to some future need) than the other way around (as we are witnessing). 4b) Unittests for core code must not depend on system (i.e. external tools, configuration, or data) -or- repository state (i.e. higher-level module availability or present TP code/tests). These are key to early organizational problem detection. 4c) TP unittests on the other hand, _SHOULD_ make liberal use of available code-code and unittests. However, dependence on system state is still forbidden. These are also key to early organizational problem detection. 4d) If/when #3 is violated due to review or mistake, the original author is responsible. That implies the consequence is in fixing all subsequent commits piled on top before detection. i.e. this could mean re-working a LOT of other people's layered commits. 4e) If original author is not available, the re-write responsibility falls to the reviewer(s), then it goes up the chain from there. -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
