Document migrators

In “Knowledge Base” and elsewhere, we talk about migrations (grep “migration” or “migrator” in the raw doc files, ex: under CUDA/Apple Silicon sections), but AFAIK we never carefully explain to maintainers

• What is a migrator/migration and what does it do?
• What issues the “Rebuild for …” PRs? (Ans: the migrator)
• How to write one, and where does it go? (Ans: see here)
• When can (and why would) I reject a migration PR?
• How to resolve rerendering conflicts between the migrators and a local conda_build_config.yaml?

The last item is the most painful and subtle pitfall. The applied order is global pinning -> local pinning from conda_build_config.yaml -> migrators (see https://gitter.im/conda-forge/conda-forge.github.io?at=60335ce247585464db940db3), but maybe @isuruf or @beckermr or someone from @conda-forge/core can confirm. Often if there is a conflict, the rerendering would fail obscurely and it’s hard to debug.

@viniciusdc This may require more prerequisite knowledge of the Conda-Forge infrastructure than other documentation tasks, so I am not sure if it’s suitable for the outreachy participants and I’ll leave it for you and the core team to decide 🙂

[viniciusdc]

I’ll take this up, @viniciusdc. But @leofang says:

This may require more prerequisite knowledge of the Conda-Forge infrastructure than other documentation tasks, so I am not sure if it’s suitable for the outreachy participants and I’ll leave it for you and the core team to decide.

Yes, he is right. For now let’s just let this issue open for later reference. (I just commented there because I was really moved by this issue)

[viniciusdc]

Yes! Please we need that!