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
Camptocamp France SAS, Alexandre Fayolle
- 27/08/2015 16:29:29 
I quite like the suggestion of having information about the ported
addons in the README.md. We could list the unported / uninstallable
addons in a separate section.

And we could use the opportunity to add a short paragraph describing
what the addon does (using the summary from the manifest?). This is
something we can provide a script for in maintainer tools.

Alexandre

On 27/08/2015 16:23, Guewen Baconnier wrote:
> Setting aside the separate repos discussion, my biggest concerns are
> the corruption of the history that would be inflicted by the git
> filter-branch on renamed modules and the forward-port of merges.
> Renaming a module is not an uncommon scenario and the forward-port is
> something we really use.
> If we can find a solution for these problems, I think I could do with
> this procedure. Otherwise I would prefer the simple method of just
> setting 'installable' to False.
> 
> On Thu, Aug 27, 2015 at 11:37 AM,  <Pedro@pad.odoo-community.org> 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 __init__.py 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 ^`, 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?
>>
>> Regards.
>>
>> 2015-08-27 11:07 GMT+02:00 <Mozetič@pad.odoo-community.org>:
>>>
>>> -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
>>> <quentin@quentin-theuret.net> 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.
>>>>
>>>> Regards,
>>>> --
>>>> Quentin
>>>>
>>>> _______________________________________________
>>>> Mailing-List: http://odoo-community.org/groups/oca-contributors-15
>>>> Post to: mailto:contributors@odoo-community.org
>>>> Unsubscribe: http://odoo-community.org/groups?unsubscribe
>>>
>>>
>>>
>>>
>>> --
>>> Matjaž Mozetič, CEO
>>> +386 41 745 131
>>> www.matmoz.si
>>>
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/oca-contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe
> 


-- 
Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

Reference