openerp-community team mailing list archive

[Lionel Sausin <ls@xxxxxxxxxxxxxxxx>]

Le 04/07/2014 23:05, Raphael Valyi a écrit :
> Sometimes, if a core method is so badly designed that really it's 
> impossible to extend it multiple times, then consider that some base 
> module "monkey patch" the offensive bad method and transforms it into 
> a decent citizens for overriders. <subliminal_message> You know it's 
> why I mad at trying to get these kind of no-brainer changes in the 
> core before the release https://github.com/odoo/odoo/pull/915/files 
> </subliminal_message> <subliminal_message> and hell that one two 
> https://github.com/odoo/odoo/pull/913 </subliminal_message>
I'd like to add that some changes are a lot easier/cleaner to maintain 
as patches than modules.
Monkey-patches are pretty hard to maintain because you can't use version 
control to help you.
Example:
- 12 lines patch, works fine
https://code.launchpad.net/~grupocitec/ocb-addons/report_webkit_custom_paper_size/+merge/195418
- same feature as a monkey patch module, 189 lines, was right at first 
but now introduces regressions because the monkey-patch is outdated
https://code.launchpad.net/~bruno-bottacini/report-print-send/7.0-report_webkit_custom_paper_size/+merge/202892

Basically when the core is not modular or needs an obvious fix, on our 
site we've decided to :
1/ patch the core to make it modular or fix it
2/ push our patch to a clean, mergeable, maintainable branch on 
Launchpad/GitHub
3/ propose the branch for merging into the next core version (trunk/master)
4/ propose the branch for merging into the current OCB
Then by the time we migrate to the next version, hopefully the core is 
fixed/modular and we can drop our patch.

Lionel