Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Migration to version 9
by
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
> Mozetic has reminded us a truth that we tend to forget too often: the > end user is our sponsor and is the one we need to please. > It is an excellent discussion and it's not one module repos specific Conclusions could still apply if we don't go that way. > > Somehow we need to rely on github/apps for distribution unless we > build our own infrastructure (which is out of scope for the moment): > we need to improve the current way our work is hosted and distributed > in Github. > There are two main user cases to address for end users: 1) Module discovery 2) Module installation Today the "end user" way to do both is only through apps.odoo.com. For the module discovery alternatives, this can be GitHub or a custom catalog. IMO GitHub will never provide the best end user experience, whatever repo organization you choose. One alternative is to create a GitHub "reference catalog" repository, with a automatically generated static web site (, by a script crawling the OCA repos. I used that approach to build the openerpapps.info catalog. It is still available (but outdated): http://openerpapps.info/content/oca/7.0/index.html. The "try online" with OCA Runbot and better demo data of course would be very helpful. Developers hate to write demo data; if only we had an easy way for functional users to contribute them (module_builder?). > - Major difficulty today is to download 500 repos: a good script for > end users OR a mirror of all modules to a repo container would be easy > to arrange. End users would only have to pull that container in their > main directory and restart Odoo (with all limitations of such move!). > This repo (or docker or recipe) could contain only stable modules (or > a mild idea of certified ones). > - We talk about bundler/recipe etc. There is an easy way to bundle: > create a meta-module with dependencies. Whoever wants to create one is > welcome: it requires few technical skills and it is easy to create a > specific repo for it/them. It might need an uninstall function or > procedure but nothing very difficult to implement. > Regarding module distribution, the repo organization is not relevant. End users don't want to use Git for that, so some type of packaging is needed, and it's implementation can mask the underlying repo organization. An end user solution for this could be: 1) Good: A "download me" button on the module catalog website (and GitHub README files?). 2) Best: an "OCA catalog" app, similar to the Odoo Module List feature, that pulls the module index data from GitHub and allows to download modules and dependencies with a button click. This would also solve the module discovery use case. Not quite there, but I have done a few things in that direction, such as https://github.com/dreispt/ooenv and https://github.com/dreispt/ooenv-index. > Getting "one module=one repo" is leaner, simpler and more flexible on > the structural point of view. I understand it is challenging on the > technical side but current model does not scale up and we need to > think about best evolution or a middle ground to get there. > Maybe some volunteers could do a proof of concept with a particular project, such as a verticalization or a smaller localization? --Daniel
Reference
-
Migration to version 9
byOpen Source Integrators, Maxime Chambreuil-
Re: Migration to version 9
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis