Contributors mailing list archives


Re: Migration to version 9

Camptocamp SA, Yannick Payot
- 31/08/2015 09:14:36

*  The migration will consume a lot of resources to make the changes on Github, Travis, Coveralls, Codacy, Transifex, Runbot, Apps, the OCA website

For travis and runbot, we would need a simpler dependency discover than the oca_dependencies.txt we use now as dependencies would be name of repo or in official addons. No need to maintain the oca_dependencies anymore, plus builds would be lighter.

About fears to manage in a one module = one repo I think it's a win as needed quite a lot of emails to the odoo support for each modules which moved from one repo to another making all modules of one repo not updated.
It is possible to import csv files, so for the first one shot import it's would be the almost the same to generate a singe csv file including all repo if they are 100 or 500.

About resources, I gave some of my free time to start developing a script to split modules in a one per repo basis to experiment on this as I strongly believe it would be a win on multiple aspects and the only reason to not do it seems to be resources issue not that the actual state is better thus it should be the way to go.

My main concern was about not loosing history, so I rm -rf all existing directories that are not the module I want. Letting the history include all directories which have been deleted or moved in the past which could be optionally reworked.

At least I hope it will be use to migration to 10 as we could be postponing what we already postponed in 8.0 migration but longer we wait, heavier will be the change.

Yannick Vaucher
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: +41 21 619 10 30
Office: +41 21 619 10 10

On Mon, Aug 31, 2015 at 10:37 AM, Raphaël Valyi <> wrote:
Hello OCA people,

So between the proposed migration solutions: I vote for:
"installable: False"
For the same reasons as Guewen.

Now about the 1 module = ! repo thing. I totally understand we cannot afford it for the v9 migration. But in fact my preoccupation is exactly to alleviate the PSC/reviewer bottleneck too you know...

But we don't have to be binary in our choices. Things can be progressive such as:
  1. we try not splitting our existing repos
  2. we would be closer to 1 module = 1 repo for new modules that don't get a strong consensus they are central. Call that incubator if you like. Look I only see that PSC/reviewer workload will not scale if the number of modules per repo double every year or so... Soon that will be like the old extra-addons thing again...

Now, even if we try not splitting our existing repos, we may eventually have a simple but formal rule to make things more modular and also properly partition the PSC work:
  1. in general an OCA repo is based on an Odoo root module such as sale, purchase, stock...
  2. we can say that a root OCA repo should depend only on one root Odoo module (but it can be mrp for instance that is depends on bothy sale and purchase for instance).
  3. Localizations would be an exception however as they could depend on any Odoo SA modules.
  4. if a given module depend on several Odoo modules or several Odoo repos (except may be server-tools), then this module should belong to another repo. Modules with similar dependencies belong to the same repo for now (untill eventually further split happen as package management matures enough)

What do you think?


Post to: