1. Mailing Lists
  2. Contributors
  3. Re: Proposal to support small repos into the current OCA workflow

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Proposal to support small repos into the current OCA workflow

Re: Proposal to support small repos into the current OCA workflow

Avatar

Re: Proposal to support small repos into the current OCA workflow

by "Pedro M. Baeza (Tecnativa)" <pedro.baeza@tecnativa.com> - 30/06/2016 02:12:47
OK, I get it. But I don't see the rest of the flow from the inclusion of the module. If your plan is to continue maintaining the module in its subrepo, we will lose the tests for all the modules together, which can be sometimes a way to discover errors in our own module. We lose also the control over that repo, that will be owned by other person, so future patches can be merged by the PSC.

Regards.

2016-06-29 20:53 GMT+02:00 Daniel Reis <dgreis@sapo.pt>:
My idea is to have a script to every night merge satellite repos into the integration repos.

For deployment you can choose to clone the integration repo, or clone directly the satellite repos, depending on your needs.

--
Daniel

No dia 29/06/2016, às 19:38, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> escreveu:

Hi, Daniel,

Thanks for your efforts, but if I understand well, this is only one part of the flow, the testing one, but the subrepo still continues in another location and for a deployment, what do you have to do? Download all satellite repos?

Regards.

2016-06-29 20:23 GMT+02:00 Daniel Reis <dgreis@sapo.pt>:

Hello all,

I implemented the changes needed to MQT and have a first PoC for the "satellite repo integration".
The changes are proposed here: https://github.com/OCA/maintainer-quality-tools/pull/338

Suppose that "dreispt/business-requirement" is to be made a satellite repo for "dreispt/project".

I then need to make a PR on "dreis/project" adding business-requirement to the oca_modules.txt file.
Like this: https://github.com/dreispt/project/commit/9319888871f1

The TravisCI build is expected to automatically merge the repos in oca_modules.txt and then run the tests.
And indeed we can see TravisCI testing all modules from the "project" and "business-requirement" repos.
The log is at: https://travis-ci.org/dreispt/project/jobs/141143843


This feature could enable small repos in our workflow, while keeping backward compatibility and many of the advantages of the existing "integration repos".


Regards
Daniel
 

 

Citando Daniel Reis <dgreis@sapo.pt>:

I think those methods only allow to integrate repos as a subdirectory.
We need the integration to happen right at the root directory.

I could be wrong, but if so, ready to discuss the merits of those alternatives compared to a simple git pull/merge.
 

/DR

 

Citando David Arnold <dar@devco.co>:

Sound's very good! However, I guess the role you are assigning at oca_modules.txt is what any of git submodules, git subtree, git submodule can do at the git level. as all of those are mostly warppers arround basic git commands, the ours strategy will be waranted.

However the idea of all three commands is not to mess with the top level but be "in charge" specifically of one folder.

I think this is more or less just what's needed out of the box?

Best, David

Luis Felipe Miléo <mileo@kmee.com.br> schrieb am Do., 23. Juni 2016 um 01:08:
Very nice +1
 
This will bring many benefits to the l10ns.
 
 
=D
 
- Luis Felipe Miléo
Gerência de Implementação
Parceiro oficial:
  
 

De: "Daniel Reis" <dgreis@sapo.pt>
Para: "Contributors" <contributors@odoo-community.org>
Enviadas: Quarta-feira, 22 de junho de 2016 9:23:22
Assunto: Re: Proposal to support small repos into the current OCA workflow

 

Hello all,

I conducted a first experiment on this workflow.

GitHub only allows to create PRs from forked repositories.
So the proposal to integrate a new repo needs to be done differently.

My idea is to keep a "oca_modules.txt" file in the integration repos, similar to the existing "oca_dependencies.txt".
This file lists the satellite repos to integrate in the reference repo.
A nightly script would perform, for each line, the following command:

    git merge -X ours https://github.com/OCA/$SATELLITE_REPO -b $BRANCH

The "ours" merge strategy keeps the integration repo top level dotfiles (.travis.yml, README, .gitignore, CONTRUBUTING.md, etc).

So, proposing to add a new repo should be creating PR to add a line to the "oca_modules.txt" file.
To follow the changes and discussion, people need to manually follow the proposed repository.
The best the author can do is to later post  reminders on this PR if it needs more people to come into the discussion.

I couldn't test the ownership transfer to the OCA, but it seems that the original owner should add the OCA organization as owner ,and then remove himself: https://help.github.com/articles/transferring-organization-ownership/


After this, we could merge the PR adding the repo to the "oca_modules.txt" file.
It would be desirable to be able to confirm that integrating the new repo would keep TravisCI green.
For this, we should improve the MQT, so that it merges the proposed repo and lets us see how the tests work after the merge.
The git-subrepo extension could be helpful here, but I worry if it supports merge strategies, since the "-X ours" is really necessary.


Sounds good?
I would like to start an experiment on OCA/project, and already have an idea for the candidate repo.


Regards
/DR

 

Citando Graeme Gellatly <gdgellatly@gmail.com>:

Hi,

At airport so can't elaborate but take a look at https://github.com/ingydotnet/git-subrepo#readme. Then you can have atomic repos, aggregate ones, ppl just working on what they need, distribution repos etc. Tbh I've not used this yet, but did use git subtree which worked really well.

On Mon, 20 Jun 2016 3:53 AM Daniel Reis <dgreis@sapo.pt> wrote:
 

Just a tiny comment: Would it be bad to suggest a OCA-dev organization? This prevent's cluttering the actual nicly organized repos. Yet this might be a technical detail and you already conceived it that way. 

Indeed, an OCA-dev org could provide a nice sandbox for contributors to collaborate.
But crowd discussions are hard, and it's best to keep the discussion topic narrow and focused.
I believe that it is something we can bring up at a later time.
 
/Daniel
 

_______________________________________________

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


 

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


 


 

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe



_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


Reference