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
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 27/08/2015 15:23:13
Let's explore the one module one repo idea.

Building on Pedro's comments and putting aside migration technicalities, how would the PR workflow work?

IMO it's not feasible to not have aggregation repos. Managing hundreds of independent small repos makes PSC work a nightmare.

From Graeme I take that the module coordination is done from a repo with submodules. Either a big single one (barely manageable IMO) or several repos by topic (similar to today).

I imagine that to propose a new module to OCA I need to:
1. Open an Issue on the topic repo for my module repo to be created.
2. Make the initial PR for that module once it is created.
3. Make a second PR to add the submodule to the topic repo.

For the review:
1. The review would go in the module repo. Interested people would need to manually add it to watched repos.
2. Unit tests are checked in the module repo PR and Integrated tests are checked in the topic repo PR (MQT needs changes to support the latter, but it's doable).
3. When changes are added to the module PR, the repo PR also needs to be updated and resubmitted (git submodule update && git push). This will also trigger new integration tests.
4. A successful review means two merges by maintainers. An unsuccessful review and at a repo deletion, or most likely an empty and inactive repo.

For maintenance and direction:
1. Issues should be on the topic repo, and disabled at module level (IMO)
2. Fixes and improvements should follow the double PR described above.

I probably forgot something, but I see a lot of moving parts here. It for sure complicates new contributions.


--DR

No dia 27/08/2015, às 13:08, Pedro@pad.odoo-community.org escreveu:

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