Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Re: Migration to version 9

by
Tecnativa. S. L., Pedro M. Baeza
- 27/08/2015 14:00:13
I think you're forgetting one of the parts of the one module per repo tasks: the creation of a new module:
  • Everyone cannot start a new branch under OCA umbrella to host their new module.
  • At least 2 PRs have to be done: one for the new branch and another for the git-subtree repo (if possible).
  • Check that Travis/runbot and so on lead correctly with this structure.
  • ...

But as Leonardo has said, we can try with a pilot. Leonardo, are you going to do it or may I? We can also join for doing the test.

Regards.


2015-08-27 13:38 GMT+02:00 Graeme Gellatly <gdgellatly@gmail.com>:

mozetia and Pedro that is not what subtree is about or I think what anyone talking about single repo per module is envisaging.

To rule it out out of hand without discussion 2 months before a decision is needed seems to defy the purpose of asking for discussion in the first place.  I really think it is an option worth exploring. 

The idea with git subtree and the purpose of the experiment is entirely opposite to what you say.  It is to reduce overhead. Now truthfully I don't know if it will work,  as I say,  I can see already 2 possible technical issues.  Of course if it turns out to be a nightmare we abandon it. 

The idea is that a module can be updated from any repo in which it exists.  So from a general perspective perhaps it is managed exactly as it is now or perhaps we have a single product and issue queue.  Certainly noone is thinking 400.

But also a module could exist in more than one repo and users could create and work on their own collections.  You could have one repo with all modules for transifex. 

The existing configuration is entirely arbitrary,  and by your argument we should therefore have just one repository.  No cross repo dependencies,  single management and single Travis config.  Indeed just one repo is probably better than what we have now in a lot of ways. 

But I really don't know,  it looks good on paper but until I try I won't know. 


Sent from TypeMail

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 ^<tag>`, 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

_______________________________________________
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


Reference