Home

Welcome to the maintainer-quality-tools wiki!

OCA Repo health board

Procedure for adding new rules (proposal):

Option 1 We created an organization called https://github.com/orgs/oca-travis with this org, pro-active fixes to repos can be done without affecting ongoing projects on oca before merging the new changes to the rules.

1. Before adding new rules, make sure a majority of projects are green (see the controlboard https://github.com/OCA/maintainer-quality-tools/pull/48). If they aren't, an effort should be done to get these tests to work with the current rules.
2. Make sure the community is informed about the new rules. I am talking an email not an obscure PR or Issue that only the most hardcore reviewers will see.
3. Make a PR
4. Accept PR with 3 people, do not merge yet.
5. Give a deadline before the new changes take effect, so that repos can be ready
6. The ones proposing a new rule, must participate in fixing the errors pro-actively(ie. code sprint), a script to fork all repos in the org oca-travis and test them using a the MQT from PRs should not be very complicated to write.
7. Close to the deadline, audit the repos on oca-travis and see if the deadline should be extended.
8. Remind the community
9. Merge PR on MQT and pylint fixes from oca-travis
10. Update the wiki to document these new rules.

At this point if the community complains, point to the emails and show that procedure was followed.

Option 2

Assuming we have one test branch for each test level, we should not add new tests in a branch. We should create a new test level (= branch). Each project would then climb the test ladder at their own pace. It would be easier for new projects to join and start at the bottom of the ladder with less strictly tests. It would also allow anyone to easily measure the quality of a project code.

Travis style rules

Config files can be found in https://github.com/OCA/maintainer-quality-tools/tree/master/travis/cfg

Flake8 Rules:

• Default flake8 rules
• max-line-length = 79
• ignore unused imports (F401) in __init__.py only

Pylint Rules:

(all these can be seen with pylint2 --help-msg <msg-id>[,<msg-id>])

• E0101 return-in-init: Used when the special class method __init__ has an explicit return value.
• E1124 redundant-keyword-arg: Used when a function call would result in assigning multiple values to a function parameter, one value from a positional argument and one from a keyword argument.
• E1306 too-few-format-args: Used when a format string that uses unnamed conversion specifiers is given too few arguments
• W0101 unreachable: Used when there is some code behind a "return" or "raise" statement, which will never be accessed.
• W0102 dangerous-default-value: Used when a mutable value as list or dictionary is detected in a default value for an argument.
• W0104 pointless-statement: Used when a statement doesn't have (or at least seems to) any effect.
• W0105 pointless-string-statement: Used when a string is used as a statement (which of course has no effect).
• W0109 duplicate-key: Used when a dictionary expression binds the same key multiple times.
• W0403 relative-import: Used when an import relative to the package directory is detected.
• W0404 reimported: Used when a module is reimported multiple times.
• W0621 redefined-outer-name: Used when a variable's name hide a name defined in the outer scope.
• W0622 redefined-builtin: Used when a variable or function override a built-in.
• W1111 assignment-from-none: Used when an assignment is done on a function call but the inferred function returns nothing but None.
• I0013 file-ignored: Used to inform that the file will not be checked

Odoolint Rule:

• EO001 print statement used: Used when there is a call to print