Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Question about Module Structure
by
dar
Hi Tom
Thank you for coming back! Most appreciated!
In advance: I took the chance of despair to build a clean, but somehow complex workflow and was now able to back and forth changes through subrepo's content hash mapping strategy (no real object hashes as in normal git).
My working directory is like this:
- modules a/ - a subrepo
- modules b/ - a subrepo
- modules c/ - a subrepo
- odoo-cc/ - a submodule
- odoo-ee/ - a submodule
I use submodule where the development is mostly decoupled and I do not need own adaptions in the mainline git history.
I use subrepos where I need modifications in the mainline git history, for example in order to be able to craft clean changelogs automatically or in order to parse the commits and detect a scripted migration flag/hint for the CI.
Now upstream and my subrepo have diverged, so I'd like to feedback changes and pull in upstream into my mainline history. Not an easy task at first sight.
How I actually managed it, finally:
In order to do all the necessary manipulations in addition to my subrepo, I proxy origin locally and have a downstream fork in github (for the PRs).
Rough steps:
1. In my lokal proxy, I create a patched/10.0 branch
2. On that branch, I init all subrepos which I'm going to use as individual modules in my working dir with "." as remote (magic hack!) so to easily push changes later. Single Module branches prefixed with subrepo/ are created.
3. I squash the numerous init commits and give it a visually very distinct commit message (to find it easily in the history).
I'll be constantly rebasing this commit and following patches in order to keep atop of origin evolvement.
4. I do, in my main working dir, git subrepo clones for every module from the local remote, specifying their respective single module branch.
5. I hack something.
6. Something's hacked in upstream.
7. In main workdir, I first do a git subrepo push pushing my changes to the local proxy (to the submodule branch)
8. In local proxy, on patched/10.0, I git submodule pull in the changes.
9. I then rebase patched/10.0 and resolve conflicts.
Note: Now, I finally can cherry pick to prepare upstream PRs and honour reciprocity.
11. I then subrepo push --force from patched/10.0 to populate the subrepo branches with the updated and rebases working tree.
12. From main workdir, I do git subrepo pull to pull in the rebases changes and rebase. However, as rebasing has mainly taken place on patched/10.0 already, and If I didn't overlook anything, I should be able to cleanly git rebase --skip all rebasing commits.
Eureka! ;-) But I'll still have to refine that further.
I'll probably have to wrap that into some scripting one day... :-)
@ Lasley
Given that git submodule as shown above can work with local submodule branches there is a possibility to keep current repo structure but do general module development on subrepo/ branches. This has the same benefits on clean collaboration while not coming with the problems off-access-right repo creation. Federated commits across multiple subrepos are fairly easy to manage in the main workdir.
What would be your workflow?
Best Regards,
David A.
El 7/03/2018 1:37 a.m., "Tom Blauwendraat" <thomaspaulb@gmail.com> escribió:
Hi David,of course improvements are always good, but they take time to reach agreement and so on.Until then, couldn't you just work the same way as "most" people currently do?I can share my workflow, but before spending time on it, I wished to check again what are your problems currently, because my workflow is quite basic and I wouldn't want to spend a long time typing up information that you most probably already know!Greetings,Tom - Sunflower ITOn Tue, Mar 6, 2018 at 10:17 PM, David Arnold <dar@xoe.solutions> wrote:Hello,I'm once again stuck knee deep in not knowing how to synch my working-dir project bugfixes back to upstream and vice versa...As I assume such fundamental change needs it's good period for articulating itself until it might eventually have a chance of broader acceptation,I'd like to ask if anyone has developed an alternative workflow which works with the current module structure which he/she can share with me?Any help would be very welcome! The relevant commits are already buried deep in my history...Best Regards,David A.El vie., 2 mar. 2018 a las 20:33, David Arnold (<dar@xoe.solutions>) escribió:As to the bot, meet derek https://blog.alexellis.io/derek/ Pretty amazing :)El jue., 1 mar. 2018 a las 16:06, David Arnold (<dar@xoe.solutions>) escribió:Hi Again,I just learned that some people actually responded and it never got to my email inbox (some issue with emails here?)So I copy from the public archive and try to respond as best as I can:Dave:How would a new module be proposed to the OCA under this type of organization?/R There would be indeed some person or bot be in charge of that. Preferably a bot..
Pedro:GIT subrepos are very limited, as they freeze specific subrepos commits.Having pip + docker deployment initiatives like https://github.com/Tecnativa/docker-odoo-base , I don't see that needed./R I think Graem clarifiedDaniel:Things can change as fast as we can have a general agreement on them.The current Module Lifecycle document is at a final stage, after many months of open discussion, and we really need to move on with what achieved general agreement.So it’s best to close it ASAP rather than going back to square one.This doesn’t mean a freeze on these processes. Proposals to evolve it are always welcome, and can start being discussed any time./R thanks again for guidance. I hope we can keep evaluating pro's and con's of this idea independently of the already agreed document. The main PRO is an incredible ease of custom mix and matches with a transparent and super-easy workflow to feed back own improvements.Graeme:git-subrepo is quite different to git subrepos/submodules. Its kind of a parallel evolution of git stree. I've used it for about 18 months. Some things it fits perfectly, especially when you just need to pull in genuine external dependencies (i.e. js libs), or a real decoupled dependency required across multiple versions. But it doesn't really fit Odoo's module structure as it is, plus it has some fun unresolved bugs that would really affect it in an OCA context. But if you have time, it is worth a play with. At the same time, the complexity of managing it beyond simple use just isn't worth it atm IMO. As soon as you hit something that hasn't been considered, you are kneedeep in StackOverflow issuing 20 archaic git commands wondering what the hell it is that you are doing./R It would be interesting to hear some examples of where you got stuck... The only thing I got stuck is with transparent rebasing onto upstream in one single command. That's where I used git subhistory (another fancy tool). But the only reason I wanted to use git subtree is actually because I did fetch single modules into my working tree and then wanted to feed back cleanly. Ended up being a mess, but with a one-repo-one-module structure, I really do not see anything else needed than git subrepo pull & git subrepo push.My main argument about this idea is inline with the objectives of the initial document: Improve dynamism and contribution across the OCA. I personally regularly think twice before adapting a OCA module because it means basically a fork, as I have no easy and efficient way to feed back any changes. And it is very frighting to work with monolithic folders with lot's of modules where you probably need only 2 of them.I see that there is a pip based workflow, but this does not integrate very well into the git based development cycle and all other hack I've tried like sparse checkout are really hard to maintain and confusing Combined with eliminating noise from monolythic repos it would be able to get everyone more focused and fun about contributing would come back.It would be nice to hear you opinions about the PROs as well. I think CONs will always pop up naturally (conservatism bias), so let's re-frame for the sake of balanced public opinion forming:How would this be able to make your life as a contributor easier?How would you assess the impacts on potential contributors (which do not contribute at the moment)?How might that potentially benefit the OCA ecosystem?Can such measure ultimately be apt to create a new dynamic around OCA at the technical level?Best Regards, David A.El jue., 22 feb. 2018 a las 14:35, David Arnold (<dar@xoe.solutions>) escribió:Hello again,Following through Daniel Reis's kind guidance and suggestion,
I found out that I can fork the document with suggestions.I spared out the module quality levels, as this seems to be of urgent concern and scheduled for asap implementation.Therefore, please share your ideas on:A little show-off (a picture says more than thousand word): https://asciinema.org/a/tUg6ND6VERFL4ZehSQgj0cRiL You can check the result here: https://github.com/xoes-oca/sales_team_multicompany/pu ll/1 Best Regards,David A.El jue., 22 feb. 2018 a las 14:22, David Arnold (<dar@xoe.solutions>) escribió:A little show-off (a picture says more than thousand word): https://asciinema.org/a/tUg6ND6VERFL4ZehSQgj0cRiL You can check the result here: https://github.com/xoes-oca/sales_team_multicompany/pu ll/1 El jue., 22 feb. 2018 a las 13:23, David Arnold (<dar@xoe.solutions>) escribió:Hello,I've been thankfully pointed to the fact, that I missed the main discussion by two-three weeks.Now, I'm not sure if this proposal is counter-productive or if it would probably in it's clarity and conciseness have a real chance of being taken into account be the steering committee.I would really wish to see a simpler contributing workflow.I think everyone faces this problem at some point.And I also think a lot of beneficial impetus gets turned down silently because of those obstacles.It addresses the issues of the discussion at its best and most condensed expression.I hope this opportunity for change did not already pass by freezing the world for the next 3-4 years until further contributing statistics impose further reactions to the OCA ecosystem.Best Regards,David A.El jue., 22 feb. 2018 a las 12:41, David Arnold (<dar@xoe.solutions>) escribió:Hello,I think I've found the right frame and initiative to place my thoughts: https://docs.google.com/document/d/1wwnu7oe5cDTyjZ H3hdKkGLnF6fH4jPP3RLMPAhm3gjs/ edit#heading=h.7w9he6vxmsoc It's a great document and initiative!Best Regards,DavidEl jue., 22 feb. 2018 a las 10:43, David Arnold (<dar@xoe.solutions>) escribió:Addendum:As an alternative solution to the organization problem could count to split out the one-module-one-repo into a oca-dev organization and then do tagged packages in oca which resembles the current structure (using precisely git subrepo approach). That way the impact of such a move is mitigated without leaving out the benefits.El jue., 22 feb. 2018 a las 10:37, David Arnold (<dar@xoe.solutions>) escribió:Dear OCA Members,--Dear OCA Steering Commitee,Dear OCA Board,I've tried on several occasions to work with OCA repos, but it somehow doesn't fit any simple, easy to remember development and upstream-commit workflow I've been able to come up with.In despair, I tried to do a PoC of a one-module-one-repo structure https://github.com/xoes-oca There is a extremely useful tool called git subrepo (combinable with git subhistory) I've found to be the perfect solution for the problem to incorporate upstream modules in own code, do improvements with close to 0 changes to your normal workflow and just git subrepo push to upstream those chages transparently and cleanly.Problem is that doesn't work out of the box with topic repositories, so it basically breaks my ideally perfect workflow and then again going the extra mile is often too cumbersome in the heat of the battle.If we would have one-module-one-repo the contributing workflow becomes as simple as that:...Using hub by github (https://hub.github.com/)hub fork git@github.com:oca/foogit subrepo clone git@github.com:myuser/foo foo# do some commits touching module foo within my current working dirgit subrepo pushhub pull-request> Pull request created: https://github.com/oca/foo/pulls/208 Wouldn't that be something that's worth evaluating to boost contribution and ease of adaption?
I'm principally very in favor of the OCA iniciative, but honestly contributing has those (solvable) hurdles and gets rather cumbersome (for the new generation of iphone-ux-socialized programmers).Let me know what you think about, I'd be happy to more closely integrate our development efforts with OCA one's.And if there are concerns about code organization, I guess since github allowed for topics this can be easily replicated with using topic filters: https://github.com/search?q=topic%3Aproduct+org%3Ax oes-oca&type=Repositories
Best Regards,David A.
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. --
DAVID ARNOLD
Gerente Generalxoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender. Environmental Consideration: Please avoid printing this email on paper, unless really necessary. ______________________________
_________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Reference
-
Question about Module Structure
bydar- 22/02/2018 16:37:02 - 0-
-
-
Re: Question about Module Structure
byDatenbetrieb Technologie UGh, Peter Niederlag- 07/03/2018 08:01:51 - 0 -
-
-
-
-
-
-
-
