Community mailing list archives
Re: Proposal to review the OCA contribution guidelinesby
Akretion, Raphael Valyi
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 <email@example.com> wrote:
Hello all, I certainly agree that not a single customer is interested in a PEP8 compliant solution. However, when an issue in the module surfaces, a customer 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 keep that in mind. However, the point that Luc raises is valid indeed. If a lot of code is being published outside of oca there will be no gain in maintainability at all. We always should consider restrictions very carefully. Regards, Jos -- Jos De Graeve - Apertoso business ICT http://www.apertoso.be/ Guido Gezellelaan 16 - B-9800 Deinze - Belgium Direct: +32 9 381 64 51 General:+32 9 381 64 50 Mobile: +32 475 54 68 80 mail/im/skype: Jos.DeGraeve@apertoso.be - apertoso
Luc De Meyer