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
Camptocamp SA, Yannick Payot
- 27/08/2015 14:20:57 
* Everyone cannot start a new branch under OCA umbrella to host their
new module.

IMO this is a good thing as it would need to change the process, first
step would be describing the module or roadmap to create it.
We could have an incubator repository and the module should be
accepted by the PSC. It might require more people with access to repo
creation.

+1 to experiment it first
Leonardo you have my keyboard!
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
http://www.camptocamp.com/


On Thu, Aug 27, 2015 at 2:08 PM,  <Pedro@pad.odoo-community.org> wrote:
> 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
>>
>> On 27 Aug 2015, at 9:37 PM,
>> Pedro@pad.odoo-community.orgServ.@pad.odoo-community.org 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 __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 ^`, 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
>>>> www.matmoz.si
>>>>
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> 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