Brad, 2026-09-09, during the v1.29.0 patch survey: "I'm questioning whether we should handle MicroPython differently somehow and get away from mailbox patches, especially for the 3 types: windows networking, ffi and wasm. Maybe continue keeping our camera and usbif mailbox patches." Decision deferred until the CircuitPython 10.3.0 / MicroPython 1.29 pin move is complete; the patches get re-derived for this move regardless.
Why these three and not the others. They are not ours by nature. Windows sockets/select/ssl under MSVC, Windows FFI, and the five WebAssembly fixes are upstream's business as much as ours — every MicroPython release can touch the same lines, so each one is a hand rebase forever. The survey bore that out: 0001, 0003, 0005 and 0006 all conflicted with v1.29.0, while the device-specific cameraif and usbif patches mostly held.
The camera and usbif patches are different in kind: they exist because a user C module needs a hook MicroPython does not offer, they touch few upstream lines on purpose, and nobody upstream is asking for them. Those stay mailbox patches.
What makes this worth recording now. Two of the four — Windows and wasm — cannot be tested at the moment they are re-derived. There is no Windows build and no wasm build until later in the move, so they get rebased blind and stay unverified until then. That is the recurring cost of carrying them this way, and it lands again at every release.
Options to weigh when this is taken up (none chosen):
- Upstream them. The best outcome per patch: a conflict that cannot happen again. Slowest, and not all will be accepted.
- Convert to added files plus build configuration, the way the CircuitPython side already works — 51 copied files that cannot conflict against 13 modified ones that can. Only some of these are shaped for it.
- Keep them, but shrink the upstream surface each one touches, so a release moves fewer of our lines.
- Drop the ones we no longer need.
cameraif-02 turned out to be exactly this — v1.29.0 defaults MICROPY_HW_ESP_NEW_I2C_DRIVER to 1 on ESP-IDF >= 5.5.2, so upstream absorbed it. Worth asking of every patch before rebasing it.
Survey and evidence: docs/effects-internal/audits/pin-move-mp129-survey.md in the workspace anchor. Related: the routine's section 1 (docs/pin-move-routine.md) says shrinking the modified-upstream surface is the only lever with compounding returns.
Brad, 2026-09-09, during the v1.29.0 patch survey: "I'm questioning whether we should handle MicroPython differently somehow and get away from mailbox patches, especially for the 3 types: windows networking, ffi and wasm. Maybe continue keeping our camera and usbif mailbox patches." Decision deferred until the CircuitPython 10.3.0 / MicroPython 1.29 pin move is complete; the patches get re-derived for this move regardless.
Why these three and not the others. They are not ours by nature. Windows sockets/select/ssl under MSVC, Windows FFI, and the five WebAssembly fixes are upstream's business as much as ours — every MicroPython release can touch the same lines, so each one is a hand rebase forever. The survey bore that out: 0001, 0003, 0005 and 0006 all conflicted with v1.29.0, while the device-specific
cameraifandusbifpatches mostly held.The camera and usbif patches are different in kind: they exist because a user C module needs a hook MicroPython does not offer, they touch few upstream lines on purpose, and nobody upstream is asking for them. Those stay mailbox patches.
What makes this worth recording now. Two of the four — Windows and wasm — cannot be tested at the moment they are re-derived. There is no Windows build and no wasm build until later in the move, so they get rebased blind and stay unverified until then. That is the recurring cost of carrying them this way, and it lands again at every release.
Options to weigh when this is taken up (none chosen):
cameraif-02turned out to be exactly this — v1.29.0 defaultsMICROPY_HW_ESP_NEW_I2C_DRIVERto 1 on ESP-IDF >= 5.5.2, so upstream absorbed it. Worth asking of every patch before rebasing it.Survey and evidence:
docs/effects-internal/audits/pin-move-mp129-survey.mdin the workspace anchor. Related: the routine's section 1 (docs/pin-move-routine.md) says shrinking the modified-upstream surface is the only lever with compounding returns.