Contributors mailing list archives
Re: Proposal to support small repos into the current OCA workflowby
Sorry, ai did not pick up one point of your reply, as it is rather implicit:
- Do you see git pull / merge as the baseline or the "built in" proposed tools, if they could solve the use case?
I would argue that the generic solution (porposed tools) should merit precedence over a custom development as per the many desirable side effects such as upstream improvements, broadend use cases, boradened solution also for slightly differen use cases, etc.
Daniel, you are absolutely right about this. Am I correct in assuming, that the (only) case supporting this requirement is the following:
Case: I'm working on a funcionality, that I want to ultimately include into the consolidated repo. However, following the modluar approach, I want to split my work up into three different modlues, which are an incremental set of functionality, that can be sern as a whole.
Are there more?
If this is so, wouldn't it be a viable option to reach out to Olivier Dony and discuss with him the possibility of including module set's at a lower tree hirarchy? As far as I know, currently they *must* reside at the top level. However, it seems easy to me to adapt the loading method to scan the tree for manifest files. If there is concern of a performance penalty (for whatever reason) it could be still limited at two levels. This would enable a great deal of organization into the wealtho of functionality developed in general and would help to elegantly solve the exposed case "on the fly".Daniel Reis <firstname.lastname@example.org> schrieb am Do., 23. Juni 2016 um 17:53:
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.
Citando David Arnold <email@example.com>:
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, DavidLuis Felipe Miléo <firstname.lastname@example.org> schrieb am Do., 23. Juni 2016 um 01:08:Very nice +1This will bring many benefits to the l10ns.https://github.com/odoo-brazil/odoo-brazil-banking
https://github.com/odoo-brazil/odoo-brazil-reports=D- Luis Felipe MiléoGerência de Implementação+55 35 email@example.comParceiro oficial:
De: "Daniel Reis" <firstname.lastname@example.org>
Para: "Contributors" <email@example.com>
Enviadas: Quarta-feira, 22 de junho de 2016 9:23:22
Assunto: Re: Proposal to support small repos into the current OCA workflow
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.
I would like to start an experiment on OCA/project, and already have an idea for the candidate repo.
Citando Graeme Gellatly <firstname.lastname@example.org>:
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.Indeed, an OCA-dev org could provide a nice sandbox for contributors to collaborate.
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.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
ThinkOpen Solutions Portugal, Daniel Reis