Contributors mailing list archives

contributors@odoo-community.org

Avatar

Re: Migration to version 9

by
Open Source Integrators, Daniel Reis
- 31/08/2015 08:15:13
> 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