Contributors mailing list archives


Re: OCA Code sprint: sprint topics

Open Source Integrators, Maxime Chambreuil
- 12/09/2017 15:35:17
+1 for v10 modules only with installable = False

Ursa Information Systems Maxime Chambreuil
Project Manager / Consultant

Ursa Information Systems
1450 W Guadalupe Road, Suite 132
Gilbert, Arizona, 85233

Office:     1-855-URSA ERP x 710
                1-855-877 2377 x 710
Mobile:   1-602-427-5632

On Tue, Sep 12, 2017 at 5:23 AM, Pedro M. Baeza (Tecnativa) <> wrote:
No, not installable modules are not "reserved" in Odoo Apps for the first coming. The module name is taken when the daily scanner checks that is installable, so indeed that argument doesn't serve.


2017-09-12 12:08 GMT+02:00 Sylvain GARANCHER (SYLEAM) <>:
I'm in favor of creating an empty branch for each new version, and add the modules one by one in the migration PRs :
- We don't lose history, thanks to our migration procedure.
- Each branch will contain only available modules : No more issues/questions about not installable modules or modules not working because the user just changed the installable flag to make it appear in Odoo.
- Each branch will contain only currently available modules commits : history is easier to read, the repo is smaller for people who use shallow and/or single branch cloning.
- When migrating a module that has not been migrated for the previous version, we directly take the last working version : I already saw PRs for 10.0 based on the 9.0 branch, but the module was not migrated to 9.0, and the 8.0 version had bugfixes in the meantime.
- Cherry-picking bugfixes will work, even if the module never existed before in this branch, so this is not a problem.
- We can review only the diff of the migration (either using GitHub or our local git).
- We already have modules in some branches that are not in the latest branch (modules added at version X-1 after the verison X branch was created), so not seeing all modules in the latest branch is not a new issue. And it will be more consistent here : currently, we are between "all modules are in the latest branch" and "only available modules are in the latest branch".

I think the reason raised by Graeme is not an issue : "On the more cynical side, to stop unscrupulous 3rd parties pinching module names for app store and/or just porting and claiming as their own."
Odoo already helped us in this way (OCA's modules included in proprietary wensite themes, for example). But I don't know for modules that have the same name, but are completely different...
Also, how does it work currently ? Does Odoo Apps list applications that are not installable ?


2017-09-12 11:23 GMT+02:00 Andreas Stauder <>:
What is about fixing bugs or adding features in an earlier version (e.g. 8.0)? We do cherry-picking and create a new PR for 9.0 and 10.0, right? Does this still work when a addon is removed because it was not ported in two versions, but will added again for a later version? On the other side: When a module was dead for two versions it should stayed buried and replaced by a complete new one (especially with the API change since then).

So I vote for removing addons not ported since 2 versions, but keeping the other ones and setting them uninstallable as it was done for 10.0. 


On Tue, Sep 12, 2017 at 10:38 AM, Eric Caudal <> wrote:


Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore)
Odoo Gold Partner // Best Odoo Partner APAC 2014 and 2016
On 09/12/2017 03:53 PM, Jairo Llopis wrote:
<blockquote type="cite" cite="">
I'd personally love to see the 11.0 branch completely empty of uninstallable addons, and grow as they become migrated.

The git size problem is not a problem for me anymore, because since long ago I got used to always clone shallow repositories (git clone --depth 100 $repo), so the size does not matter much.

Our migration instructions take care of keeping history, and you can review only the migration commits in a PR nowadays, so the little diff in PRs is not a need anymore.

This would remove garbage code and the need to explain many "whys".

Just my 2 cents :)

Jairo Llopis

Post to:

Post to:

brain-tec Group 

 +41 (0) 44 552 01 20
 Technoparkstrasse 1 ▪ CH-8005 Zürich
Andreas Stauder 
Head of Development, Consultant und Projektleiter

Certified Professional Scrum Master
brain-tec AG
Technoparkstrasse 1
CH-8005 Zürich
brain-tec AG
Saflischstrasse 4
CH-3900 Brig
brain-tec AG
Rue de la Madeleine 38
CH-1963 Vétroz
brain-tec Germany GmbH
Otto-Lilienthal-Straße 36
D-71034 Böblingen
brain-tec Spain S.L.
Calle Velazquez 138
ES-28006 Madrid
 Best Odoo Partner EMEA 2016

Post to:

Ce message et toutes les pièces jointes (ci-après le "message") sont établis à
l'intention exclusive de ses destinataires et sont confidentiels. Si vous
recevez ce message par erreur, merci de le détruire et d'en avertir
immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer
l'intégrité de ce message, SYLEAM décline toute responsabilité au titre de ce
message, dans l'hypothèse où il aurait été modifié.

This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender. Any use not in accord with its
purpose, any dissemination or disclosure, either whole or partial, is prohibited
except after formal approval. The internet can not guarantee the integrity of
this message. SYLEAM cannot therefore be liable for the message if modified.

Post to:

Post to: