Contributors mailing list archives


Re: Migration to version 9

Camptocamp SA, Yannick Payot
- 27/08/2015 11:26:39
I disagree with you on this Pedro, IMO this must be considered as an
option. And I don't really see what we loose.

For github security management, AFAICT the job is almost done with the
tool we have that set teams on repos, we can apply the teams to new
For travis and runbot, it would return to something simple as the main
issue is the `oca_dependencies.txt` file which we could get rid of it.
I don't think the work would be huge on those. And builds would only
include needed dependencies. (avoiding thing such as uninstalled but
loaded modules)

About history, I think it is important to keep the complete history.
Each PR should be checked carefully to include it.
We have to add a step to check if in history the module was
moved/renamed. I just hope that 90% of modules haven't been renamed
and then we can automate to filter on  +

About not removing the __unported__ dir, think about the benefits of
one module per repo.

Yannick Vaucher
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: +41 21 619 10 30
Office: +41 21 619 10 10

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: