Community mailing list archives
Re: Proposal to review the OCA contribution guidelinesby
<blockquote cite="mid:firstname.lastname@example.org" type="cite">
Dear Odoo community members,
I have been following a number of mail threads recently and I think that we are navigating in the wrong direction.
I’ll make myself clear by rephrasing the OCA mission statement and an example of where it goes wrong.
The OCA mission (cf. http://odoo-community.org/ ):
“The Odoo Community Association, or OCA, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.”
My understanding of ‘features’ is ‘functionality’.
Our focus should be on stimulating the community to contribute new functionality and to improve existing functionality.
Based upon a few mail threads, we are currently adding barriers to contribution in stead of stimulating it.
I’ll illustrate my point via the following thread: OCA/maintainer-quality-tools#46.
The OCA guideline is that new contributions should be PEP8 compliant.
This guideline adds an extra barrier to people who want to contribute modules.
Why should we reject modules that comply to the following criteria
- The module adds extra functionality
- The module is compliant with the coding practices of the EDITOR (not the OCA)
- The module is compatible with the standard modules from Odoo
We are adding modules on top of the Odoo suite of business applications. None of the modules from Odoo are PEP8 compliant.
The vast majority of the current OCA modules are not PEP8 compliant.
Since I am working with OpenERP/Odoo (5 years now) I have never seen an RFP nor a customer demand to deliver a PEP8 compliant solution.
Hence why should we add this extra barrier ?
I personally find it hard to motivate myself to restyle a module that is working fine for many years in order to make it PEP8 compliant (with the ‘punch card age’ line length limitation as the most extreme one since I don’t like to spend even a minute of my time in order to make code harder to read and maintain).
Having a clean code base is important, because it eases the maintainance work. The coding practices of the editor, while interesting to be aware of, are by themselves not enough, and in a number of places, the code published as part of Odoo core is way below all standards that I know of (although it is generally improving, which is a good thing). I personnally wish the whole odoo code base was PEP-8 compliant (to start with).
We should reject modules with obscure code, we should reject modules which were not written with maintainability in mind. Most importantly we should reject modules for which no-one, not even the person proposing it, cares enough to to the little bit of reformatting required to make it PEP8 compliant, because how can we expect that anyone will care enough to fix issues related to this module?
We should also, IMO, reject modules which come without automated tests.
The code quality you deliver to your customers is your problem. The code quality you deliver to the community is the community's problem.
-- Alexandre Fayolle Chef de Projet Tel : + 33 (0)4 79 26 57 94 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com
Luc De Meyer