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