What is the current policy on adding external code to modm?

[asmfreak]

If I want to implement some new feature for modm which would require an external library, what is the process on embedding it?
I remember correctly, when tinyusb was brought in, it was implemented as a separate repository?

[salkinium]

it was implemented as a separate repository?

Yes, in the modm-ext organization, which contains all our support code.
We chose to buffer external repositories ourselves for three reasons:

1. to reduce submodule sizes: We usually only need a few files from the whole project, and don't need to clone everything else.
2. to guarantee the submodule's future existance: Perhaps the external repo gets deleted, or the commit SHA we depend on gets force pushed away. We previously forked project for that reason, but that didn't make their sizes smaller.
3. The external organization doesn't spam the main org full with automated update messages and nobody's tempted to open issues on any of these repositories that are not actively maintained.

what is the process on embedding it?

I will create a modm-ext/{name}-partial repository with you as a maintainer. You then have access to the GitHub Actions CI and can hack the update.py script until you're happy.
Then you can add this repository as a submodule in ext/{org/user/vendor-name}/{name} and place a module.lb (and perhaps other support/config files) next to it and integrate it into lbuild.

[salkinium]

Note that the update.py script usually works by checking for a new release every week, instead of copying the latest changes. This prevents obvious quality issues when features are only partially implemented and reduces my workload, since I update and test these submodules on every modm quarterly release.