Re: New OCA repository to suggest

by

Leonardo Pistone

- 09/19/2014 12:35:23

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).