[RFC] Default odoo_test_flavor for recent version

[legalsylvain]

Hi all,

Context

I recently updated the copier answer of the repo OCA/pos for branch 16.0. In that occasion I wanted to switch odoo_test_flavor to "Odoo". @pedrobaeza said me that it was not a valid option so I reverted that changes.

Rational

The rational behind the proposal was the following :

• CI consume energy and it would be desirable to save it, if possible.
• if we have to choose, OCA modules should work with odoo/odoo because there are a lot of instances working on that version. OCA/OCB is very confidential.
• The paradigm to test PR with OCB is maybe not the good point. I mean:
  • if a PR doesn't work with odoo/odoo, it should be fixed.
  • but if a PR works with odoo/odoo and not with OCA/OCB, it should not be blocking for sure for the PR, and maybe it is OCB that should be fixed.
• But above all, I see OCB as an a project at the end of life. Since V13+ there are less that 10 commits per version and most of the commit are trivial. (changing some auto_install to False that could be done via other OCA recent solution with odoo/odoo and module_change_auto_install).

OCB Evolution of PR.xlsx

Proposal

• In recent version, (15 / 16 / 17) : set default to "Odoo" in the template
• allow to let OCB, to allow to test in both context for very specific cases, like the l10n_fr_oca fork done by @alexis-via. (Ref : https://github.com/OCA/OCB/pull/1138 / https://github.com/OCA/l10n-france/issues/379)

CC :

• funder : @StefanRijnhart
• commiters that makes changes in OCB on the recent versions (14 / 15 / 16) : @victoralmau, @chienandalu, @remi-filament, @alexis-via, @igallart, @MiquelRForgeFlow, @joao-p-marques

thank you for reading.

[yajo]

One of OCB rules has always been: keep it 100% compatible with upstream Odoo. Thus, the amount of changes that can really land in OCB is extremely low.

IMHO it makes sense to enable OCB in versions 14 and below because those don't have upstream support anymore. Thus, any further changes will have to land in OCB exclusively.

For upstream-supported versions (15-17), I'd turn off OCB and enable only Odoo builds. We should be able to safely assume that OCB will respect its own rules.

[pedrobaeza]

There can be patches applied to OCB in recent versions, so in any case of keeping only one version, it should be OCB, not Odoo.

[remi-filament]

Hi @legalsylvain thank you for bringing that topic to my attention.

I agree with your proposal that we could have tests with Odoo only on versions maintained by Odoo (15 to 17) although from my point of view that would mean having OCB only as default for older ones. This would mean that PSC would have to change when an Odoo version becomes EOL (from an Odoo perspective).

I would like to share with you my opinion on whether OCB should not be used anymore (or barely) though :

I am not sure OCB is that much confidential and end of life, at least for us it is a big deal and we deploy everywhere code from OCB, not from Odoo (although I agree that code should work with Odoo too). From my perspective, OCB is very important for us and for many of our customers for the following reasons :

1. It allows to have code maintained for a longer period than the 3 years from Odoo (although maintenance is reduced to backporting important fixes, in particular security fixes)
2. It is also an insurance that OCA is capable to fork Odoo at anytime to keep Community Edition code living, whatever should happen with upstream code and its license.

Personnally I prefer to go with OCB from the beginning of the project will all my customers, since most of the time they would stay on the initial version for at least 4-5 years (and sometimes more), and I do not have to change the source of code when Odoo stops maintenance of the oldest versions.

As for your graphics, I suppose it is normal that there are not so many PR merged on still maintained odoo code but more on the one which is not maintained anymore...

[rvalyi]

my 2 cents on the topic: I kind of agree with @remi-filament.

Also, even if OCB is not really different from odoo in newest versions, IMHO having OCB is really part of the OCA nuclear doctrine: "don't even think to screw Odoo CE any further or mutual destruction is guaranteed, the button is here, ready to be pushed by any surviving OCA entity."

Also, to complete what @remi-filament wrote, it's important to keep in mind that sadly switching an instance from OCB to odoo or the reverse is not as easy as one might expect. We all know an Odoo git clone is huge (shallow clones have their issues like you cannot merge a PR or it is slow like hell). So switching between OCB and odoo pratically means downloading several GB for a new clone and possibly also adapting the set of PRs you may want to merge...

So yes to avoid useless tests but opting for odoo instead of OCB in the newest versions might not be as simple...

[yajo]

I see valid points on both sides of the discussion, so maybe the best choice is to leave it as it is, with both builds.

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.