Community mailing list archives

Re: Proposal to review the OCA contribution guidelines

Nhomar Hernandez
- 08/13/2014 15:58:37

2014-08-13 14:42 GMT-04:30 <>:

Basically I think flexibility should be the responsibility of the reviewers. Your idea is great, but as there would be no easy way to attribute these starts, I'm afraid we would spend more time debating how many stars a module has than fixing things sadly. So I personally don't see it working unless it can be fully automated.

Now, indeed, many successful projects exhibit a multicriteria approach. And it works when it's fully automated.
An example, my Ooor Ruby connector for Odoo:
* test passing
* code quality (complexity analysis, DRYness etc..): 3.3 / 4
* code coverage 90%
* up to date dependencies...

If some day we can de-correlate testing from other quality metrics and still be automated on Odoo modules, I think that will be great indeed. But I don't see this happening that soon unfortunately.

I am agreed with raph Pedro and Luc that's the reason we took Internally this actions I will describe, if everybudy can move in our way (or take for themselve that's cool).

1.- No pardon for Non-PEP8 pylint passed code. [Here Pedro and actual OCA is right,] 
Simple, everybody in our company need to focus read 1 way of code and 1 way to improve things, then with these approach is really easiest find and understand algorithms behid the code (not meaning this that without PEP8 is not possible), but pylint give you some feedback about variables not defined and used, defined and not used and so on that you only see in running time frequently.

We actually have +400 modules + OCA ones, it is a Huge job to do manually.

We are building thes "specific" tests inside runbot (WIP) [1] be in touch ;-)

2.- We need to be more flexibles. (Luc is totally right)
Some times we need to move forward "fast", 


It can create w wrong perspective of quality,


IMHO the 120 lines can comply with that in terms of be more flexible for V7 and more hard to v8.0.

And this evaluation rvalyi and luc mentioned are given by the report that pylint returns then... it can help and it can be configured/validated by our approach [1].

3.- Pesence and visbility.

It is a big issue, no solution/proposal yet, maybe a "clone" for apps or wait until is supporting github.

And here rules we propose are too hard to follow, (I always has been one of the most harder supporter on that topic) then maybe we should re-think about that.


Saludos Cordiales

Nhomar G. Hernandez M.
Skype: nhomar00
Servicios IT:
Linux-Counter: 467724
twitter @nhomar