Contributors mailing list archives

Browse archives


Re: Procedure to create 16.0 branches

Open Source Integrators, Maxime Chambreuil
- 20/07/2022 13:51:00

El mié, 20 de jul. de 2022 06:07, Roussel, Denis <> escribió:
As I'm in favor of that change for so long, you definitely convinced me with the arguments you exposed.

So, +1 

On Wed, Jul 20, 2022 at 12:46 PM Stéphane Bidoul <> wrote:
Dear contributors,

I'm starting to think about the process to create the 16.0 branches. And the more I think about it, the more I'm convinced we should do it by adding "installable": False in the module manifests, instead of creating empty branches.

This would have several benefits:
  • Improve security. Indeed, currently migration PRs have a lot of commits and reviewers only look at the last 2 commits. By accident or malice, it would be easy for a contributor to sneak bad code in older commits, that would go unnoticed. As the community grows, I think this a very important topic.
  • Avoid CLA bot issues: currently, the CLA bot is flagging old commits that were ok at the time they were created, but may not be valid today as contributors may have changed email, or revoked their CLA.
  • Reduce oca-github-bot complexity: work has to be done to make the bot aware of other branches in migration PRs (notably to look-up maintainers). This would be unnecessary if a migration PR is a normal PR to an existing addon directory. On the contrary, the bot could even detect migration PRs automatically by noticing the change to the installable flag, so this could simplify some processes.
  • Slow git repo growth: by avoiding the recreation of identical commits in several branches we would slow down the git repo size increase.
About the possible drawbacks, I am under the impression that all the reasons we had back then to create empty branches have faded away:
  • Today, Odoo and all the OCA tooling work perfectly well when there are addons marked as uninstallable. They are correctly ignored by linters, tests, and Odoo does not attempt to import the code.
  • Regarding discoverability, the addons table in the README shows a clear view of what is not migrated.
The migration procedure and tools should continue to work as today, to pick up commits that would have been added after branching (basically the git-am process would simply work as it does today)

All we'd need maybe is to agree on a process to remove modules that have not been migrated for several versions. But in a first approach, regular PRs to remove now useless modules would probably be sufficient.

Are there any other arguments (pro or con) that I would have missed ?

Looking forward to reading your feedback on this proposal.


Post to:


Denis Roussel
Software Engineer
T    : +32 2 888 31 49
M : +32 472 22 00 57

Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
Zone industrielle 22 | L-8287 Kehlen | Luxembourg

Post to: