Community mailing list archives
Re: New OCA repository to suggestby
I take the ball from Raphaël on that subject. Let me share why I'd prefer 1 repo per module: - A module has versions, and I would like to tag the repo with that version. If the repo groups many modules, I can't. In my production instances, I'd like version 1.5 of module_a, and version 1.6 of module_b. Getting commit abcdef123 of the whole repo is limiting and artificial. - A module has CI status and coverage. I'd like to know the coverage of my module, it's not so useful to have a big average with other people's modules. I'd like to collect all those per-repo coverage statuses in a big dashboard (a simple static webpage with a big table full of travis/coverage badges), and see which modules really have no coverage. - Since odoo v8, a README file in the module directory is taken as the module description. I'd like to see that in github when I open the repo. On the other hand, per-repo READMEs have to be written by hand copying and pasting information. - Dependencies are from one module to another, not from one repo to another. Let me make an example: the module sale_report_webkit depends on the module base_headers_webkit. That is the "real" dependency, found in __openerp__.py. Finding out that the module base_headers_webkit is in the repo webkit_tools is an extra step that could just be avoided if module and repo had the same name. - When there is a bug being fixed in two modules that happen to live in the same repo, I cannot use at the same time the two branches. I have to create a temporary "pending merge" branch. Of course the temporary branch is still necessary when there are two fixes on the same module. - When I start coding a new module, it's easy to just make a new branch on github. If later I decide to propose it for some OCA branch, it can just change ownership. On the other hand, the reasons for grouping modules are more "organisational": - I want to find all modules related to "sale workflow" - I want to say that John Doe is responsible for the quality of modules related to "sale workflow" - I find too many repos to be overwhelming. There are some known solutions for those problems, which are: - some webpage to help finding modules, anything from a static webpage to an "apps" site to some filtered view on github - git subtrees exist to merge many repositories in one as subdirectories, creating a new branch that behaves like the ones we have now. I believe that is done for projects like Openstack and Puppet. In any case, I understand well that we already did a wonderful effort migrating all modules to launchpad the way we did, and I'm very happy with that. So, sorry for going a bit OT, and have a great weekend! > I may be wrong, but I feel it's always easier to have tooling to configure multiple repos and show consolidated indicators of them than deal with an evolution of stale cross dependencies cross firing in a growing chaos. Also, if at some point we are able to set projects or team that gather several repos, I'm actually in favor of that. But I personally prefer not moving too far away from 1 repo = 1 module that proved to be a working design pattern in so many other successful projects already (that didn't attempted to re-invent module packaging though).