Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Migration to version 9
by
Matmoz D.O.O., Matjaž Mozetič
I'm not a coder, i do not even operate on IT (except a little hacking
for my own needs), but probably is exactly for that reason that I can
approach these discussions in a dispassionate manner. The one thing that
is bothering me in all these discussions is, that you are cutting out
of the picture the one stakeholder, that shouldn't be kept out for any
reason - the end user (which in an open source project can be considered
equal to the project sponsor). No end user - no purpose for the project
(development) at the first place.
My approach to Odoo implementation is different, because I implement it per project base (and not per a single company/customer base), and my projects can be everything from product development or infrastructure construction to a simple marina management, and for me, as an advanced end user (who happens to be a contributor too) is:
- What workflow do you have in mind? I mean from the beginning (repo structure, commits, pulls, pushes, ...) to the end deployment (git pull of everything you need and deployment of an production odoo server).
If every module is in an own repo, ok, that's a project development phase, so what's the next phase, what is the path to the final repo containing the collection of the modules with their dependencies? A real project plan (or development plan if you prefer) contains all the phases, from initiation to final delivery and its closure.
That's what I miss in all of this discussion. From my point of view, the OCA project deliverable is not code commit but the final deployment of the committed code (server running, modules installable), after all the end customer does not pay us just to develop a function, but to deploy it as per his needs. I didn't construct several hundreds of kilometers of gas pipelines just as a prove of concept, i did it to bring the gas to the end users and that was what we were paid for. Am I missing something? Who are we developing for?
On Fri, Aug 28, 2015 at 12:38 AM, Graeme Gellatly <gdgellatly@gmail.com> wrote:
That stack-overflow is referring to the contrib module git-subtree which attempts to implement git subtrees. It is known to have a lot of quirks. As for that particular issue, git-stree resolves it by maintaining .gitconfig, which brings me back to my primary issue which is that it really doesn't scale for multiple maintainer collaboration easy. But I am no git expert, just happy I found a way to handle my own workflow.Daniel,Also I been going through this git subtree this morning, just a little test. For me it does exactly what I want and is simple, basically I can take all OCA repositories, split them into their own and recombine how I like in a few minutes, but the technical issues for OCA I don't think are worth the effort resolving until we really decide to go down a proper versioning path. It is basically an individual developer tool. Playing nicely with the way github teams works looks problematic.Guys,Another option that I thought of for unported is possibly to have like a 9.0-unstable or something (v8.9). I don't know exactly what I mean but a stepping stone between 8.0 and 9.0 branch. Then we could have a flow of unported's not just at release time. It is often not the case that a version 8 user who releases a module is interested in porting to v9 immediately. That way developers know where to look for prior work, and users aren't confused. I don't know, maybe.
My main issue has always been the pain of releasing a module to OCA, plus having own branches from where it originated and so on. Keeping both updated and insync and sometimes having to maintain slight differences (like module name). Or the reverse, taking a module from OCA to make changes that you just know won't be accepted but are needed, and wanting to keep history (actually aeroo reports is an excellent non OCA example of this issue). So for me, now I can hopefully in a couple of days maintain everything I want in single repos, work on what I want where I want and hopefully work out a way to handle the overhead.On Fri, Aug 28, 2015 at 8:23 AM, Daniel Reis <dgreis@sapo.pt> wrote:> You would be right if we used submodule. Subtree is different and > avoids nearly all of what you have there. At least I think. > You are right, I didn't consider the subtree option. I'm not familiar with git-subtree, so I did some research, but it points that it has it's won issues. For example, it seems that a repo clone becomes a complicated operation (judging from http://stackoverflow.com/questions/3202674/procedure-for-cloning-git-repos-that-use-subtree). Anyway, even assuming that my conclusions above are wrong, most of the workflows I described would still be valid: - You would always need the double initial PR. - Even if no "git submodule update && git push" is needed, you would still need an extra step to manually rerun the TravisCI tests for the PR of the topic repo. The burden for contributors, maintainers and repo cloning still increases compared to current situation. I also worry about the zombie repos for abandoned PRs. I have seen someone mention using an "incubator" repo for new modules. While I think that the "incubator" idea has a lot of potential for the community, and have a few ideas to share on that, I'm not sure it's something that should be introduced in our workflow before it is matured. --DR_______________________________________________
Mailing-List: http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe
--
Reference
-
Migration to version 9
byOpen Source Integrators, Maxime Chambreuil-
Re: Migration to version 9
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis