Contributors mailing list archives


Re: Split OCA website repository into website and website_sale

Matmoz D.O.O., Matjaž Mozetič
- 14/08/2015 14:26:20
I thought about that (and I actualy use it on daily basis), but:
git pull --recursive pulls the submodules checked in their last working tree commited to the main repo, so it's still needed a manual git pull on every single one of them if you want to keep them updated with the branch and finally git commit & git push on the main repo (to commit the new working trees) - it's helpful for the first install, it's helpful when you have multiple servers, since a git pull, git submodule init and git submodule update --recursive will update and check all the submodules on the last commited working tree and you need to manually maintain only one instance, but fot that one instance to keep the submodules in sync you still need a manual checkout and pull on each of them, and the final push on the main repo to commit the latest working trees;

It helps a little, but still: X repos means X pulls (or fetches), it solves only the multiple servers maintenance, but at least one of them still needs manual updating.

So fragmenting makes the life easier for the issues management and development, but still makes the life like hell for the server maintenance and translations. But at least I'm starting to understand your reasons.

On Fri, Aug 14, 2015 at 2:23 PM, Leonardo "LeartS" Donelli <> wrote:
Well the update part is not a concern of the GitHub efforts, it's your
job to set up the system in a way that's easy to maintain, update,
replicate etc. There are plenty of tools out there to automate all
this operations so that you just need a single command to update

When people look for module they do not know the name nor the source
code, they know what functionality they need and try to find a module
that does that. To help them with this process the most important
thing is descriptive module name and description, the second most
important thing is a nice categorization into different repositories.
Having different repositories instead of a single or a few *big* repos
helps tremendously also for continuos integration, pull request
reviews, and all the code upkeep which is the main work of
contributors. Again, the main purpose of OCA on github is not to
facilitate your deployment (by the way, there are plenty of people who
just use 1 or 2 or 3 OCA modules per project, not everyone has your
workflow) but to help contributors write, review, test and share
modules and help users discover the modules they need.

The transifex problem may be a real issue, but easily compensated by
the issue it would be having all the addons in a single repository: if
someone wants to checkout a single module he would have to checkout a
repo with hundreds of modules, dozen of thousands of commits, etc. A
single missing import guard in one of the modules would break every
installation. Travis and runbot builds would be unbearably slow.

2015-08-14 13:23 GMT+02:00  <Mozetič>:
> What advantage does it give fragmenting the repositories so much? OCA repos
> are already way too fragmented for a server maintainer and while finding a
> module could seem easier in a less populated repo, we open another issue -
> finding the right repo. To do a simple update of the modules we have to
> navigate between exaggerated number of folders to perform repeatedly a
> simple git pull just to have all the repos updated. How is it simpler to
> manage that way?
> Example: for a simple service company I would need at least:
> account-invoicing, hr, hr-timesheet, knowledge, management-system,
> partner-contact, project-service, sale-workflow, server-tools, web and
> website.
> What's the point of this fragmentation? Finding a module? Crtl+F does the
> job by name in a single repo, grep -r does it by content... So why? X repos
> means X git pulls just to keep in sync (or git fetch+git rebase+git pull+git
> push for the forks)... to not even mention the translation teams nightmare
> that fragmented repositories represent - Transifex translation memory is not
> shared between projects and OCA will have (between 6.1, 7.0, 8.0 and in the
> close future 9) hundred of them by this pace.
> I don't want to criticize, I just want to understand why (i started with the
> cons, give me the pros please).
> On Fri, Aug 14, 2015 at 12:52 PM, Leonardo "LeartS" Donelli
> <> wrote:
>> Hi all!
>> The OCA/website repository already contains 16 modules of which 4 are
>> actually ecommerce (website_sale) modules.
>> There are 22 PR for new modules, of which 6 are modules for the ecommerce.
>> Assuming all get merged, this would result in a repo with 38 modules.
>> By splitting the repo into OCA/website and OCA/website_sale, they
>> would have respectively 28 and 10 modules, which would make it simpler
>> to manage and to find the modules you're looking for.
>> _______________________________________________
>> Mailing-List:
> --
> Matjaž Mozetič, CEO
> +386 41 745 131
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe:

Post to:

Matjaž Mozetič, CEO
+386 41 745 131