Contributors mailing list archives


Re: Migration to version 9

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


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,  <> 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 ^`, 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č>:
>>> -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.
>>>> Regards,
>>>> --
>>>> Quentin
>>>> _______________________________________________
>>>> Mailing-List:
>>>> Post to:
>>>> Unsubscribe:
>>> --
>>> Matjaž Mozetič, CEO
>>> +386 41 745 131
>>> _______________________________________________
>>> Mailing-List:
>>> Post to:
>>> Unsubscribe:
>> _______________________________________________
>> Mailing-List:
>> Post to:
>> Unsubscribe:
> _______________________________________________
> Mailing-List:
> Post to:
> 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