Community mailing list archives
RE: Proposal to review the OCA contribution guidelinesby
I have a concrete proposal to stimulate both contribution and coding quality :
Why don’t we introduce a Technical Rating for OCA V8 modules.
We assign stars for adherence to the OCA technical guidelines, e.g.
- Test scenario’s : 2 stars
- Modules without deprecated code (use of new API, osv.osv replaced by orm.Model, version="7.0” removed from the XML forms, … ) : 1 star
- Flake8 compliance with the PEP8 allowed 120 line length : 1 star
- 80 character line length
Modules that pass all the above tests get a five star Technical Rating (functional rating is another thing but that can’t be implemented in an automated way).
If we promote these stars actively than contributors will be able to publish a zero star rated module but they will also be stimulated to upgrade their code towards a 5 star rating.
We of course need to keep a number of guidelines to reject contributions (e.g. incorrect use of inheritance, conflicting object/field names, … ) .
Rusatiralaan 1, 1083 Brussel
+32 2 808 86 38
<img border=0 width=96 height=33 id="Picture_x0020_1" src="cid:image001.jpg@01CFB734.C6F54960" alt="cid:image002.jpg@01CE271A.FF53FB90">
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: woensdag 13 augustus 2014 18:15
Subject: Re: Proposal to review the OCA contribution guidelines
I think we should be pragmatic on these things instead of being dogmatic. TinyERP and many community modules comes from quite amateurish coding standards and this is a legacy we should deal with. It's improving steadily in OCA and in the core so it's very good.
It's normal OCA to raise the bar for maintainability. We would fool ourselves if we say OCA represent any step forward without conditions to deliver maintaining and migrating OCA modules. If modules aren't migrated because they put a burden on the rare people willing to do some maintenance, soon people will point OCA as being unable to deliver in general ad will fail altogether and people defending closed source business models will rule our eco-system.
Now, not all modules in the world should target OCA. I would say only 1/3rd of Akretion modules at best go or try to go to OCA because as some said, for the other modules, even the generic ones, unfortunately we are working for small companies who don't understand software engineering and only value having the thing working tomorrow and it's not possible to fund upfront all the software quality we would always want (we all agree that upfront quality is nearly always the cheaper, but if customer doesn't understand that, there is no funding for that and we are left with a more expensive iterative process toward quality, just like when you buy with a credit if you like, it's more expensive, but still many people do it).
So people can very well put their modules anywhere they want on the internet meanwhile. It's very common that modules stay incubating 1 or 2 years, from 1 to 3 companies deployed before attempting to enter OCA. So I really see that as an iterative process. The core of Odoo itself has been such an iterative process just like so many real open source software.
Now for the legacy OCA modules, we should be pragmatic too. Because if these are modules we already massively use, we are already committed to maintain them and make them evolve at some point, just like the core of Odoo.
Now, not everybody will be willing to invest on coding styles issues on past v7 when the challenge is already ahead. So IMHO we should leave with the fact that for past versions, not all modules will meet the new standards. If some people make the investment then it's great, but if it doesn't happen it shouldn't be the end of the world.
Now, it's normal to be quite strict for new modules. Like we can hardly require that existing v7 modules get a good test coverage. But we better require that new modules enter with much better test coverage than the average and that when migrating to v8 styles and coverage increase. And yes, we can perfectly require to pass PEP-8 in v8. Because now that it's tested automatically, maintaining that PEP-8 will be free and will definitely bring maintenance benefits.
So in a word, I advocate for having a pragmatic vision; attempting the overall optimum but not missing the overall optimum because we burn too much energy on local optimums for battles of the past.
On Wed, Aug 13, 2014 at 10:09 AM, Jos De Graeve <firstname.lastname@example.org> wrote:
I certainly agree that not a single customer is interested in a PEP8compliant solution. However, when an issue in the module surfaces, acustomer expects you to fix it, even if it's not your module. Havinga clean code base will certainly help you to get the issue fixed andhelp your customer.
If a clean code base requires PEP8 compliance we should stick to that.
Anything we lose in the short term by refusing contributions should begained in the long term by easing maintainability. In any largesoftware project, maintainability is the hard part so we must keepthat in mind.
However, the point that Luc raises is valid indeed. If a lot of codeis being published outside of oca there will be no gain inmaintainability at all. We always should consider restrictions verycarefully.
--Jos De Graeve - Apertoso business ICT
Guido Gezellelaan 16 - B-9800 Deinze - Belgium
Direct: +32 9 381 64 51General:+32 9 381 64 50Mobile: +32 475 54 68 80mail/im/skype: Jos.DeGraeve@apertoso.be - apertoso
Luc De Meyer