1. Mailing Lists
  2. Contributors
  3. Re: The future of OCB

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: The future of OCB

Re: The future of OCB

Avatar

Re: The future of OCB

by
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 11/10/2016 13:10:06


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.


My .02.

--

Regards
Daniel


Citando Eric Caudal <eric.caudal@elico-corp.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
 

Reference