Contributors mailing list archives


Re: Migration to version 9

Camptocamp SA, Joël Grand Guillaume
- 27/08/2015 11:27:42
Dear Community,

Just a word on one module one repo.. That's a very old topic that always comes once or twice a year... As a reminder of what I remember:


 * Yes, it ease the release of python package
 * Yes, it give the base to better manage dependencies among module and overall versions of module dependencies
 * Yes, we know it is better from a "technical design" PoV
 * Yes, we hope to go there one day


 * Big work to move all modules out of their repos
 * Huge work to create all those new repos with proper right access...
 * Difficult for a PSC to have a look on all PR's they concerned about
 * Huge work to rewrite this page :
 * Big change for all OCA contributors, where now we finally reach a good understanding of our ecosystem from the Odoo community

Finally, it'lol need a big effort from contributors, core maintainers and OCA board member. I'm not affraid of that, but I prefer we concentrate our effort elsewhere, IMO build proper PSC with a good governance.. Once we achieved that, it'll be the time to think once again on this topic. That being said, it is just my opinion here and if all people want one module per repo, fine, I'll join the majority.



On Thu, Aug 27, 2015 at 11:37 AM, <> wrote:
Mozetič has drafted some of the several problems of separate repos for each module, but there are even more: GitHub security management, CIs (Travis, runbot) lack... so I'm afraid this is not an option because we lose more than we win.

About git filter-branch loosing renamed modules, that's true, but I think it's a minor issue because there's a lot of new modules that has landed on v8. Anyway, let me check if there's any workaround/script I can work out for this.

Letting the modules on top dir isn't an option too because some reasons that are already said and some more that I summarize here:
  • It confuses users about what modules are available.
  • It loads files, which can lead to lot of initial broken branches.
  • There are modules that are deprecated.
  • It doesn't help to recognize which ones are ported.

So I think the proposed solution is less bad. I think that we can also workaround easily the "merge question" tagging 8.0 branches when we make the split, and making `git rebase ^<tag>`, but let me check if it can be. Rebase is not the same as merge, but I even prefer this option in most times. What do you think about this, Stephane?


2015-08-27 11:07 GMT+02:00 <Mozetič>:
-1 for separate repositories, unless it's planned also a master repo containing all the oca modules in it as submodules (and regulary updated to the latest tree, but that would be an immense job with hundreds of modules in separate gits, doing git pull on each of them to push the latest working tree on the master repo), and unless the translation framework is solved too (don't even think about having 400+ projects on transifex, which don't share translation memory between them).

Another issue is: keeping all the repos updated would become a nightmare (even worse as it is already with all the currently existing OCA repos). Don't think only about the needs of a developer of a single module, think also about the ones trying to work on all of them at the same time as the translators do, think also about the end user and deployment needs.

On Thu, Aug 27, 2015 at 10:38 AM, Quentin THEURET <> wrote:
On 27/08/2015 10:08, Guewen Baconnier wrote:
> Another possibility that we should seriously consider is the one
> mentioned by Graeme: to move modules in individual repos. If we are to
> play with git filter-branch and co, it wouldn't be a big difference to
> push the modules in another repository (some other problems to
> overcome but nothing insurmountable I think).

+1 to move modules in separate repositories. With this, it will be more
easy to use only needed modules.


Post to:

Matjaž Mozetič, CEO
+386 41 745 131

Post to:

Post to:



Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28