<div dir="ltr">## Topics<br>* Hold <a href="https://pulp.plan.io/issues/8386">https://pulp.plan.io/issues/8386</a> for 3.14<br>    * could potentially break plugins (pulp_rpm) that want 3.13<br>* Possible scheme to "backport idempotent data migrations"<br>    * We cannot backport migrations, but we could wrap the migrating code into a post_migrate action on the backport only.<br>    * This can only work for pure data migrations( no schema change).<br>    * Being on the dot releases, the post_migrate code may be run arbitrarily often before the real migration (coming with the minor release) will run once. Therefore the code must be idempotent.<br>    * The post_migrate code should not appear on master ever, because it may be incompatible with later database schemas.<br>* Response to checksum migration<br>    * <a href="https://github.com/pulp/pulpcore/pull/1313#issuecomment-838075001">https://github.com/pulp/pulpcore/pull/1313#issuecomment-838075001</a><br>    * considered 3 options:<br>        * option (1): make it a no-op<br>        * option (2): make it continue even if there are errors<br>        * option (3): leave it as is<br>        * question: should the migration also download content<br>            * overall folks believe no, mostly because the common case is reducing the number of checksums not adding them<br>    * decision: go with option (2) @daviddavis to update his PR and reply to the concern<br>* Docs Backlog ( let's time box it 20mins)<br>    * <a href="https://tinyurl.com/36hc2c9h">https://tinyurl.com/36hc2c9h</a><br>* Idea/question: should we add DRF token authentication to pulpcore, can pulp-container use it?<br>* Backports for django CVE fix<br>    * 3.9 - 3.12 for pulp_deb<br>    * katello & galaxy_ng need: 3.7, 3.9, 3.11<br>    * bmbouter to release backports<br><br>## Action Items<br>[fao] write a report about upgrade tests and send on pulp-dev mailing list</div>