1. Mailing Lists
  2. Contributors
  3. Re: OCA Code sprint: sprint topics

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: OCA Code sprint: sprint topics

Re: OCA Code sprint: sprint topics

Avatar

Re: OCA Code sprint: sprint topics

by
SYLEAM SARL, Sylvain Garancher
- 12/09/2017 11:50:56
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 ?

Cordialement,
--



2017-09-12 11:23 GMT+02:00 Andreas Stauder <andreas.stauder@braintec-group.com>:
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. 

Regards
Andreas



On Tue, Sep 12, 2017 at 10:38 AM, Eric Caudal <eric.caudal@elico-corp.com> wrote:

+1

--
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="mid:CAP5xMq=oXDT7Dwg_XuOOvZ+81GWsO90TV4gCDcJF8nKU=cPbig@mail.gmail.com">
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

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


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




--
brain-tec Group 

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

Certified Professional Scrum Master
lic.iur.
 andreas.stauder@braintec-group.com
 
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

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



********************************************************************************
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.
********************************************************************************

Reference