1. Mailing Lists
  2. Contributors
  3. Re: Migration to version 9

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Migration to version 9

Re: Migration to version 9

Avatar

Re: Migration to version 9

by
rvalyi@akretion.com
- 29/08/2015 18:01:56
Hello Maxime,


You said "To those who want 1 repo = 1 module, show me the contributors to manage them."

To which I answer: yes I think 1 repo = 1 module is the only sustainable way in the long run, because it's a decentralized model that reflects very much de decentralized econonomy or ecology of open source. Now I'm not telling this should happen at v9, may be not due to the transition effort.

Yes, If the OCA has say 2000 modules to manage, if these 2000 modules becomes suddenly 2000 branch this indeed is more work and that would not be sustainable.

This is why I say: this move should be along with a reduction of scope of what is under the OCA double review process. I think the OCA and the ecosystem would be stronger if the OCA only focus on being a community backing of the core made by Odoo SA along with an interface with the community at large instead of trying to be the whole community itself, something it will never fit anyway as the ecosystem will be growing.
So my proposal is not more work for the OCA, it's the same amount of work, balancing with decentralization.

Finally let me remind you that many aspects of having 1 module =1 repo boil down to having a decent package management. And may be we don't have yet a decent package management for doing the transition on v9. Buildout is not too bad, but it's still very far away from tools such as Bundler. Again, many open source eco-system which do have a proper package manager deal just fine with 1 repo = 1 module. And I don't know any good open source ecosystem that scales to the kind of complexity an ERP is by grouping its repos in the same repos. If you know some please give me examples.

Finally, while I think we should tend toward splitting repos I think it's okay to have some grouping at the core, specially when it refelects it's under the authority of a single group of people. Like, it's okay to have 1 repo for the addons publihsed by Odoo SA, or may be it should be 5 or 6 repos like the OCA. It's Okay to have a single OCA repo for the root modules of a localization, it's may be okay to have some root OCA modules grouped for backing or another topic. Of course the limit is a grey area, but waht we could do is core reviewers vote, like for PR's if a given module is really universal enough to them to be part of these root repos. But my point is soon enough, the consensus that some module is universal enough will not exist for some module. And if despite of that, that module is still of great quality, if it does have the backing of some OCA reviewers, then it could still be an OCA module, but in it's own repo. Also, that would make it smoother to have incubating repos for projects that do not yet have the backing of enough OCA reviewers, but want to show their political intention to be part of the OCA and conform to the OCA quality standards (tests, coverage, cenventions  etc...)

Regards.

On Sat, Aug 29, 2015 at 11:53 AM, Maxime Chambreuil <maxime.chambreuil@savoirfairelinux.com> wrote:
Good morning,

My issues with the 1 repo = 1 module :
  • We will lose some history during the migration.
  • The migration will consume a lot of resources to make the changes on Github, Travis, Coveralls, Codacy, Transifex, Runbot, Apps, the OCA website
  • We don't have the tools to efficiently manage 800 repositories nor the resources to build that tools.
  • It will spread out the collaboration. Some people will work on their repo in their corner and will not get visibility, leading to few reviews and poor code quality.
  • At some point in the development/deployment process, you will need to specify the list of repo to build your environment and you will want to freeze it. On average, we install 100 to 150 modules for a customer. Managing 150 repo URL with their commits to freeze them will be a pain.
  • Same issue if you use eggs, rpm or deb packages for each module : you need the list of modules and their versions. Additional problem here is that module version today is not as reliable as the commit.
The only advantage is that it solves our current problem : new Odoo version release means new branch when we want to migrate the module. No need to remove anything. Clean and complete history.

I think the git-filter option as described on the wiki is the best trade off :
  • we keep the history
  • we provide an easy way to see which modules have been migrated
  • it allows us to match the number of repo with the resources to manage them
  • it encourages collaboration
  • it still allows anyone to deploy with packages by generating them based on module version
To those who want 1 repo = 1 module, show me the contributors to manage them.

Cheers,
--
Maxime Chambreuil
+1 (514) 276-5468 #126

----- Le 29 Aoû 15, à 7:08, Daniel Reis <dgreis@sapo.pt> a écrit :

The key to succeed with the approach of 1 repo 1 module is if we have a really extraordinay package manager, and even the official python ones are not good enought and depends too much of the programmers skills.

That's not the bottleneck. There are already two or three implementations with possible solutions (one of them for MQT).

The first problems are collaboration workflows (handling new modules and PRs) and topic governance (module compatibility and overlapping).

These are the main issues that one module repos need to address in the first place.


--DR

No dia 29/08/2015, às 08:08, Nhomar Hernandez <nhomar@vauxoo.com> escreveu:


On Sat, Aug 29, 2015 at 1:38 AM, <Mozetič@pad.odoo-community.org> wrote:
But what maintenance workflow is expected for the 1 module 1 repo approach?

I like less repos with more modules.

But all excess are wrong.

Our repositories has >500 modules and you lose the vision and migrations, quality control, SQA, CI are nearly impossible there.

One repository with more that 20 or 30 modules can be considered "Huge".

We are trying to split them also per "Area" but when you have 1 module per repository (we have few of them) all the points I mentioned above are really easy to mantain, but at the end the SQA is so reducted to a minimalistic testing approach and environment.

I think both are well it depends of the case.

Today Linux itself manage a huge separation of topics (modules) and install something brings you install hundresds of packages, but the package manager is the key (not for nothing gnu gcc is so so so old and almost untouched since time ago).

BUT anybody is totally happy with actual package managers and prefer install manually some little packages...

The key to succeed with the approach of 1 repo 1 module is if we have a really extraordinay package manager, and even the official python ones are not good enought and depends too much of the programmers skills.

THat's my opinion about that!


--
Nhomar Hernandez
CEO Vauxoo.
Twitter: @nhomar
Odoo Gold Partner
Móvil Venezuela:
+58 4144110269
Móvil México:
+52 1 4773933942

_______________________________________________
Mailing-List: http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


_______________________________________________
Mailing-List: http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--
Raphaël Valyi
Founder and consultant
+55 21 3942-2434


Reference