Contributors mailing list archives


Re: Split OCA website repository into website and website_sale

Tecnativa. S. L., Pedro M. Baeza
- 14/08/2015 14:29:25
The arguments against the spliting seems also reasonable, but Jay has made a point: why not using ecommerce repo for these modules?


2015-08-14 14:23 GMT+02:00 Leonardo "LeartS" Donelli <>:
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 everything. 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: