Contributors mailing list archives
Re: The future of OCBby
I'm confused about what OCX is supposed to be.
I think we need a clearer definition of what it is supposed to be.
With representative examples, to avois a too abstract discussion.
It can be a looser but compatible OCB, or an experimental and potentially incompatible OCX
(Or more than that but I think we all agree there are too many problems with that).
I think that an "OCB+" should replace "OCB", and that more experimental OCX-like features should be implemented in addon modules.
Explaining my reasoning:
I personally find that "OCB" is an unfortunate name:
it's more about fast merging fixes than to actually backporting stuff from later versions.
For example, backporting dome `mail` module features from 9->8 or 8->7 are not allowed, even if they do their best to keep module compatibility.
I wish our OCB would allow that. With a strong reliability and compatibility policy, just like today, but without the strict API policy.
This would not be an actual fork, but an alternative branch with actual "backports" + optimistic merges.
We could see there a policy where a feature accepted on master could be backported to this "OCB+".
For more conservative cases, having a list of fixes to merge, per current OCB policy, could be one of the services provide by such an OCB+ project.
It can be a simple bash script or a data file use by some git tool.
We could even consider keep an actual OCB straight branch around, with Odoo + API stable fix merges.
For the more extravagant experiences, Odoo is meant to be extensible by design.
They should be done in addons. Make use of the laxer OCB+ policy to introduce hooks or extension points when they are not available and needed for these extensions.
Citando Eric Caudal <email@example.com>:
I supported OCB as a clean solution because it provided stability
I do not support OCX because I think that OCX will confuse the community:
* it is not a fork but it is a fork.
* It is not OCB but it is OCB+
* It is for experiment but some modules are gonna be created on it (so supposedly for production)
Message/objective is not clear and it will divide resources that could be better employed elsewhere.
Overall I think this is not a good idea and not in favor of it in the OCA umbrella.
NB: I am not against experimentation / R&D but this is not the main objective of the OCA and we do not have the resources to do it properly