Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Question about Module Structure
by
dar
Hi Peter,
Thank you for coming back.
I didn't know about the rebase-pull option. Thanks! That will definitely ease the general workflow to some extent.
First to answer: yes, they are part of a maintain branch and deep down in the history, already.
I was responding to Tom before I read your reply. So her is the intricate problem:
Upstream history and my mainline are not connected as in "object tree". This is for I do not want to use submodules. I have worked with them and it is just not very clean to just have a commit-flipping commit without much contextual information. And it gets times worse when you have to deal with different branches and corresponding submodule states in your working dir. If you cannot treat upstream modules as per their release cycle (they have not even one in most cases) but you need to engage in active bugfix this isn't practical at all.Subrepo constructs a "content hash tree" on synthetic commit histories (using git filter-branch) to solve that precise problem of disparate histories. (As I've learned from their github wiki)
But this let's me focus on productiveness at the time of coding, which is first prio.
Thanks again for you Tipp!
Best Regards, David A.
El 7/03/2018 2:01 a.m., "Peter Niederlag" <peter.niederlag@datenbetrieb.de> escribió:
Hi David,
are your bugfixes already part of production branches or public/team
history?
If not, git rebase is a very good approach to isolate patches from the
history and re-apply them on the tip of "any" branch.
Actually I always suggest to set "git config branch.autoSetupRebase
remote". This way your local patches will always be rebased when you
pull, until you are ready to push them.
Maybe this is something that can help you?
Best Regards,
Peter
On 06.03.2018 22:17, David Arnold 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?> *Best Regards,*
> Any help would be very welcome! The relevant commits are already buried deep in my history...> David A.> As to the bot, meet derek https://blog.alexellis.io/
> El vie., 2 mar. 2018 a las 20:33, David Arnold (<dar@xoe.solutions>) escribió:derek/ [1] 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 [2] , I don't see that needed.
> */R* I think Graem clarified
> *Daniel:* 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.> *Best Regards, *David A.
> 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?>> *Hello again,*
> El jue., 22 feb. 2018 a las 14:35, David Arnold (<dar@xoe.solutions>) escribió:> Following through Daniel Reis's kind guidance and suggestion,> Therefore, please share your ideas on: https://docs.google.com/
> 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.document/d/1WFsREZ0cygoiW- [3]tTsZwrLCSkQ2DVa6aXMEvQncaUSKk/ edit?usp=sharing
> A little show-off (a picture says more than thousand word): https://asciinema.org/a/tUg6ND6VERFL4ZehSQgj0cRiL [4] You can check the result here: https://github.com/xoes-oca/sales_team_multicompany/pull/1 [5]
> *Best Regards,*> David A.> A little show-off (a picture says more than thousand word): https://asciinema.org/a/
> El jue., 22 feb. 2018 a las 14:22, David Arnold (<dar@xoe.solutions>) escribió:tUg6ND6VERFL4ZehSQgj0cRiL [6] You can check the result here: https://github.com/xoes-oca/sales_team_multicompany/pull/1 [7]> 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.> *Best Regards,*
> 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.> David A.> *Hello,*
> El jue., 22 feb. 2018 a las 12:41, David Arnold (<dar@xoe.solutions>) escribió:
> I think I've found the right frame and initiative to place my thoughts: https://docs.google.com/document/d/ [8]1wwnu7oe5cDTyjZH3hdKkGLnF6fH4j PP3RLMPAhm3gjs/edit#heading=h. 7w9he6vxmsoc
> It's a great document and initiative! *
> * *Best Regards,*> David> *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:43, David Arnold (<dar@xoe.solutions>) escribió:> 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 [9]> 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.> https://github.com/ingydotnet/git-subrepo [10]> 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/ [11] )
> hub fork git@github.com:oca/foo git subrepo clone git@github.com:myuser/foo foo # do some commits touching module foo within my current working dir git subrepo push hub pull-request > Pull request created: https:// github.com/oca/foo/pulls/208 [12]> Wouldn't that be something that's worth evaluating to boost contribution and ease of adaption?> 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=
> 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.topic%3Aproduct+org%3Axoes- [13]oca&type=Repositories
> *
> Best Regards,*
> David A. --
> None [14] DAVID ARNOLD
> Gerente General
> xoe.solutions [15]
> *Confidentiality 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. --
> None [16] DAVID ARNOLD
> Gerente General
> xoe.solutions [17]
> *Confidentiality 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. --
> None [18] DAVID ARNOLD
> Gerente General
> xoe.solutions [19]
> *Confidentiality 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. --
> None [20] DAVID ARNOLD
> Gerente General
> xoe.solutions [21]
> *Confidentiality 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. --
> None [22] DAVID ARNOLD
> Gerente General
> xoe.solutions [23]
> *Confidentiality 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. --
> None [24] DAVID ARNOLD
> Gerente General
> xoe.solutions [25]
> *Confidentiality 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. --
> None [26] DAVID ARNOLD
> Gerente General
> xoe.solutions [27]
> *Confidentiality 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. --
> None [28] DAVID ARNOLD
> Gerente General
> xoe.solutions [29]
> *Confidentiality 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. --
> None [30] DAVID ARNOLD
> Gerente General
> xoe.solutions [31]
> *Confidentiality 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 [32]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [33]
>
>
> [1] https://blog.alexellis.io/derek/
> [2] https://github.com/Tecnativa/docker-odoo-base
> [3] https://docs.google.com/document/d/1WFsREZ0cygoiW- tTsZwrLCSkQ2DVa6aXMEvQncaUSKk/ edit?usp=sharing
> [4] https://asciinema.org/a/tUg6ND6VERFL4ZehSQgj0cRiL
> [5] https://github.com/xoes-oca/sales_team_multicompany/pull/1
> [6] https://asciinema.org/a/tUg6ND6VERFL4ZehSQgj0cRiL
> [7] https://github.com/xoes-oca/sales_team_multicompany/pull/1
> [8] https://docs.google.com/document/d/ 1wwnu7oe5cDTyjZH3hdKkGLnF6fH4j PP3RLMPAhm3gjs/edit#heading=h. 7w9he6vxmsoc
> [9] https://github.com/xoes-oca
> [10] https://github.com/ingydotnet/git-subrepo
> [11] https://hub.github.com/
> [12] http://github.com/oca/foo/pulls/208
> [13] https://github.com/search?q=topic%3Aproduct+org%3Axoes- oca&type=Repositories
> [14] http://xoe.solutions/
> [15] http://xoe.solutions/
> [16] http://xoe.solutions/
> [17] http://xoe.solutions/
> [18] http://xoe.solutions/
> [19] http://xoe.solutions/
> [20] http://xoe.solutions/
> [21] http://xoe.solutions/
> [22] http://xoe.solutions/
> [23] http://xoe.solutions/
> [24] http://xoe.solutions/
> [25] http://xoe.solutions/
> [26] http://xoe.solutions/
> [27] http://xoe.solutions/
> [28] http://xoe.solutions/
> [29] http://xoe.solutions/
> [30] http://xoe.solutions/
> [31] http://xoe.solutions/
> [32] https://odoo-community.org/groups/contributors-15
> [33] https://odoo-community.org/groups?unsubscribe
>
mit freundlichen Grüßen,
Peter Niederlag
--
Dipl. Ökonom Peter Niederlag
Geschäftsführender Gesellschafter
Lösungen für digitale Zeiten
TYPO3, Odoo und Linux
Datenbetrieb Technologie UG(haftungsbeschränkt)
Lipper Hellweg 146, 33605 Bielefeld
Geschäftsführer: Peter Niederlag
HRB 41826 Amtsgericht Bielefeld
Telefon 0521 / 446 958 60
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 -
-
-
-
-
-
-
-
