Contributors mailing list archives
Re: One module one repoby
Open Source Integrators, Maxime Chambreuil
Few questions to those who ask for 1 repo per module:
Are you doing this for your non-OCA modules?
Can you provide a link to your Github organization where we would find 1 repo per module?
Do you have a tool to manage them? What is that tool?
Do you have a Runbot to build instances and combining those repos?
How often do you create a repo for a module? How long does it take to do it? Do you think it would scale for 2000+ modules?
On Wed, Jun 19, 2019 at 12:07 PM Dmytro Katyukha <email@example.com> wrote:
We had experience with approach "One repository for one module" when we was starting work with odoo.
It is really impractical. More modules (repository) harder to maitain them.
It is ok, when you have 1-5 modules, in this case it is easy to maintain them, having separate repository for each module.
But when you have 50 modules or more, when each module have it's own repository, with complex recursive dependencies, then it becomes really difficult to maintain them.
For example, you hire new developer. and you ask him to modify some addon, so he have to clone all it's dependencies (including recursive) to be able to deal with it. And what if this addon have 10 direct dependencies and 50 indirect?
More complexity added in case you have private repositories. In this case, it wil require you to grant access to each repository separatly. And do not forget to revoke access for all repositories separately.
And what if you have to maintain 200 addons? 500 addons? more?Also, each repository have to have CI configuration (.travis.yml or .gitlab-ci.yml, etc) and it have to be kept up to date in all repositories.
One of the reasons for [odoo-helper-scripts](https://katyukha.gitlab.io/odoo-helper-scripts/) project was to manage such complex recursive dependencies.ср, 19 черв. 2019 о 19:42 Stéphane Bidoul <firstname.lastname@example.org> пише:My current point of view is that one module one repo is totally impractical indeed.The reasons are:- infrastructure maintenance and scalability as Pedro mentioned- also very important is that the repos must be designed around a mix of functional consistency and willingness of a team and PSC representative to maintain their contentDeployment considerations are irrelevant to the design the repo structure IMO.Best regards,-sbiOn Wed, Jun 19, 2019 at 5:32 PM Pedro M. Baeza (Tecnativa) <email@example.com> wrote:This simply can't be done due to OCA infrastructure, with runbot, Travis, Weblate, etc and all the maintenance burden they bring.Regards.