proposed-migration needs to copy migrateable packages from proposed to release and then delete them from proposed. At present it does this by calling Archive.copyPackage (which schedules an asynchronous copy job) and then if that succeeds it calls SPPH.requestDeletion (which operates synchronously). This mostly works well enough in practice despite being ugly. However, there are some edge cases where it goes wrong:
* It is possible for the copy job to succeed but the deletion to time out or similar. In this case we end up with stray publications in -proposed that need to be cleaned up by hand. (This is minor.)
* It is possible, though thankfully rare, for the copy job to fail with an OOPS or similar, but the deletion to succeed. This is bad as it causes the upload to go missing and require manual resurrection. Hopefully somebody will notice ...
* It is possible for the async copy jobs to run after the deletion is processed, and furthermore narrowly possible for the publisher to run in between the deletion and the copy job. In this case everything will sort itself out on the next publisher run, but there will be a window where the upload in question will be missing from both release and proposed pockets in the published archive, causing considerable confusion.
The correct fix for all of these is to have a transactional "move package" operation in Launchpad. I would suggest that it could simply be a move=True keyword argument to Archive.copyPackage, which is passed down through the PCJ to the copier itself and causes a deletion at the end of the copy before committing the transaction.
Almost there, but I forgot to declare "move" as a parameter to Archive.copyPackage in the webservice API, so it isn't usable yet. Oops.