Contributors mailing list archives


Re: Migration to version 9

Guewen Baconnier
- 27/08/2015 16:20:45
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: