To be on the safe side, I'd like to highlight issues that *might* need to be RC blockers. Please reply directly onto the issue, I'll update this thread periodically if necessary.
REST API, backwards incompatible changes: - Add Task Names: - https://pulp.plan.io/issues/2889 - IMO: We should make this an RC Blocker, because this will be an additional requirement for every task in every plugin. - Determine mutable fields - https://pulp.plan.io/issues/2635 - IMO: someone (or a group) should take this as assigned and audit the mutability of fields. If we find one that needs to change, it will be a backwards incompatible change to the REST API, so this should have the RC blocker tack. - Status API without db connection - https://pulp.plan.io/issues/2850 - IMO: RC blocker or close. As it is the db connection field is not useful, and later removal would be backwards incompatible. - Add new field, Publication.created - https://pulp.plan.io/issues/2989 - IMO: RC blocker or close, this would be a backwards incompatible change. - Asynchronous Distribution update/delete - https://pulp.plan.io/issues/3044 - IMO: RC blocker or close, this would be a backwards incompatible change. Packaging - Port dependencies to Python 3 - https://pulp.plan.io/issues/2247 - IMO: It seems like if this weren't done, we'd be having problems. Anyone mind if I close this one? If we do need to keep it open, should it be an RC blocker? - Plugins can declare PluginAPI version - https://pulp.plan.io/issues/2656 - IMO: Are we happy with what we've got now? If we want to change it, now is the time. Misc - pulp-manager migrate order - https://pulp.plan.io/issues/3062 - IMO: RC Blocker. This is how users should migrate, so it should be correct before RC - jwt - https://pulp.plan.io/issues/3248 - This was removed from Beta (MVP) but do we need this for RC/GA?
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev