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.
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)
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.
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/
This doesn't scale that well (lots of LOC for every module, lots of times to CI to finish).
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.
Allows to make the APIs between modules more mature, allow better scaling.
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.
As you might know, I've always been a proponent of the multirepo solution. However, the
rspeccore team seems to regret their decision, arguing some of the cons stated here. Haven't read it all since I just found it, but I will since I think it will be interesting for us and it might make me change my current opinion: rspec/rspec-core#2509.