Community mailing list archives
RE: Proposal to review the OCA contribution guidelinesby
I’m curious about the motivation for oca.apps.com.
apps.odoo.com is integrated into the technology, so by hosting apps elsewhere they won’t be easily discoverable or available to users. Visibility suffers and people have ‘another’ place to look.
From: Luc De Meyer [mailto:email@example.com]
Sent: Thursday, August 14, 2014 1:39 AM
Subject: RE: Proposal to review the OCA contribution guidelines
Let’s indeed wait on further feedback before starting to implement something.
Rusatiralaan 1, 1083 Brussel
+32 2 808 86 38
Well it can, but will you do it?
You can do it, not sure if people will accept though, so it's risk you can take. May be wait others feedback before.
On Wed, Aug 13, 2014 at 4:55 PM, Luc De Meyer <firstname.lastname@example.org> wrote:
Why can the rating not be automated if the coding guidelines are clearly defined ?
Subject: Re: Proposal to review the OCA contribution guidelines
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.
On Wed, Aug 13, 2014 at 4:00 PM, Luc De Meyer <email@example.com> wrote:
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, … ) .
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.
I certainly agree that not a single customer is interested in a PEP8
compliant solution. However, when an issue in the module surfaces, acustomer expects you to fix it, even if it's not your module. Having
a clean code base will certainly help you to get the issue fixed and
help 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 be
gained in the long term by easing maintainability. In any large
software 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 very
--Jos De Graeve - Apertoso business ICT
Guido Gezellelaan 16 - B-9800 Deinze - Belgium
Direct: +32 9 381 64 51General:+32 9 381 64 50
Mobile: +32 475 54 68 80mail/im/skype: Jos.DeGraeve@apertoso.be - apertoso
Luc De Meyer