Community mailing list archives


Re: New OCA repository to suggest

Camptocamp SA, Joël Grand-Guillaume
- 09/23/2014 17:12:50
Dear community,

First, thank you for your interest and answer here. Not easy to know what to do with all those divergent opinions.

I want to remind that this topic wasn't really about the old-topic: one repo = one module... We all agree that in an ideal world, this is the best solution (or at least I think so).

The thing is, we DO NOT HAVE THE RESOURCES for that : who will split all those modules into repos, who will manage the OCA website accordingly and so on...? Currently, we struggle under the workload, we starts to have tens of mails each day within the OCA mailing lists that deserve answers that we can't even sometimes make... And trust me, we're doing our best at it !

So we need to find acceptable and realistic compromises. I wish we can always go for the best solution, but the reality is different...

I understood here that you're all mostly in favor of having this new project, but don't agreed on one or two repos.

Unless it really harm someone here, I'll go for only one repo for the time being, so we'll have:

- 1 repo for the core connector framework (like connector)
- 1 repo for each vertical aspect (like connector-ecommerce)
- 1 repo for each dedicated connector on a specific app (Magento, Salesforce,....)
- 1 repo for all interfaces (like odbc, XMl, csv, etc..)

It seems reasonable to me... It's not like we're about to manage all this in only one repo...

Best regards,


On Sat, Sep 20, 2014 at 7:07 PM, Raphaël Valyi <> wrote:

these things or more mid/long term but I think Leonardo Donelli made some good points here. Basically it's extremely important OCA leaves the module author visibility very explicit because it's really a large part of what can make it sustainable to invest in OCA: you can save on marketing expenses on all kinds because OCA gives you back some acknowledge of your skills and dedication in the project (other large economic motivations are integrated roadmap and lower maintenace costs through better quality and shared work).

Let's be lucid: tomorrow some people may value Odoo a lot by trying things like hijacking the license or trying to take over the whole network the license suddenly it's worth a lot of money at the expense of our freedom. Against such plans, an open source way of doing things will only stand if it is economically sustainable for community members to invest on open source. The license doesn't make it easy, but that's the rule we all accepted to build what we built years ago and now, that's also the only warranty of freedom, so we should not screw the other remaining aspects of the business part of the thing.

Now, technically speaking, I think Leonardo Donelli presented something doable:

There are some successful projects where indeed, root repos are just a curated list of git revisions to pull to assemble the software.
An example, look how Getchef (formerly Opscode) disribute its Erlang Chef server:

This repo is almost empty but this is where you will pull from: it's only a curated list of valid commit to pull from other repos. And that works great.
And this is recursive, look for instance:

Here there sometimes bother with putting a flag, but most of the time a module version is simply a commit revision that is properly pinned in the dependencies specification.

In their case, it's the packaging rool (Rebar) that does the work. Other projects work the same with other packager.

So we certainly have other priorities for now, but I personally would like such way of doing in the future.

Another random though about having modules together in a branch: I think that is an acceptable topology for modules that OCA reviewers agree they are important and generic if and only if it leaves the repo depending only on the official addons branch repo (and mat be a unique OCA repo too like server-tools, to be debated). If another dependency is needed, that could be a formal rule to use to tell today that the module should already live in it's own repo.


On Sat, Sep 20, 2014 at 1:22 PM, Leonardo "LeartS" Donelli <> wrote:

Daniel: your point 1 is the solution to point 2.
Submodules are fixed at a certain stable commit an to be updated one would do a pull request to update the submodule commit.

Post to:


Post to:



Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28