TECH Team (technology)
#Metadecidim Spreading out the developer community
Monorepo or mutiple repositories?
Last comment by
Participants
3
Groups
0
Reference: MDC-DEBA-2018-02-33
With our current architecture we're facing a crossroad, where we need to talk about how could be the best approach to handling all the git repositories and all the problems that we're having right now and the problems to come.
Starting point
On one hand, this is the picture right now:
Official modules on decidim/decidim
decidim-accountability
decidim-admin
decidim-api
decidim-assemblies
decidim-budgets
decidim-comments
decidim-core
decidim-dev
decidim-meetings
decidim-pages
decidim-participatory_processes
decidim-proposals
decidim-surveys
decidim-system
decidim-verifications
Official modules outside decidim/decidim
decidim-module-consultations
decidim-module-sortitions
decidim-initiatives
decidim-results
decidim-module-blogs
decidim-module-mentions
Non official modules
Census (DIBA)
Crowdfundings (podemos-info)
DataViz (Barcelona)
Debates (Barcelona)
Members (FundAction)
Pol.is (OSP)
Surveys (Hospitalet)
User Export (OSP)
Verification Census API (DIBA)
Verification Census API (Barcelona)
Votings (podemos-info)
Two possible roads
Monorepo
This is mostly how we're working right now. The only difference between what belongs on decidim/decidim right now are not technical issues but mostly administrative reasons (which company has made that development). This would involve moving all the Official modules outside decidim/decidim to Official modules on decidim/decidim.
Pros
This is simpler, specially because it allows the APIs to change on any given moment and make that change on a single PR, and all the CI and translations on the same place. Also simpler to grep.
A couple big companies that had this model are Google and Facebook. More info: https://danluu.com/monorepo/
Cons
This doesn't scale that well (lots of LOC for every module, lots of times to CI to finish).
Multiple repos
Most of the modules of Official modules on decidim/decidim should go outside, leaving a leaner core module:
decidim-admin
decidim-api
decidim-core
decidim-dev
decidim-pages
decidim-system
All the other modules would be on separate repositories.
Pros
Allows to make the APIs between modules more mature, allow better scaling.
Cons
This have some pain points, regarding:
Translations: we should create a new crowdin project with their integration
CI: configure again. Maybe with dummy apps and default configs it's a little less pain
Docs?
Issues
Having somekind of generators or a skeleton on making a new gem would reduce these pain points.
Report inappropriate content
Is this content inappropriate?
Close debate
What is the summary or conclusion of this debate?
Comment details
You are seeing a single comment
View all comments
I think this debate is very important and should be resolved quickly, right now we have some modules working on separates repositories within Github's Decidim organization (initiatives, blogs, consultations, etc.). It is very hard to maintain these, test services, translation services, etc. need to be set up for each repository. Particularly when a module belongs to the core functionalities of Decidim it should be included on the main core repo, so it can be integrated and maintained easily. We can't afford to maintain multiple repos. A different scenario applies to modules that are more plugin-like, meaning they serve specific feature needed for a particular case or that are out of the main features that should ship with Decidim for most organizations.
Loading comments ...