1. Mailing Lists
  2. Contributors
  3. Re: Question about Module Structure

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Question about Module Structure

Re: Question about Module Structure

Avatar

Re: Question about Module Structure

by
dar
- 03/03/2018 02:33:50
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 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.

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.

A little show-off (a picture says more than thousand word): https://asciinema.org/a/tUg6ND6VERFL4ZehSQgj0cRiL

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

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/1wwnu7oe5cDTyjZH3hdKkGLnF6fH4jPP3RLMPAhm3gjs/edit#heading=h.7w9he6vxmsoc

It's a great document and initiative!

Best Regards,

David

El 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/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

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%3Axoes-oca&type=Repositories


Best Regards,

David A.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.
--
XOE Solutions DAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.solutions
+57 (315) 304 13 68
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.

Reference