Please create a morgue/cruft pocket

I suspect a component would be better - it could even be published to an alternate archive (like partner) so as not to be confused with anything supported and released. We need a way to block packages from release, but keep them around for the next DistroSeries. As we don't have the unstable/testing split, this is about the only way that can happen.

Right, certainly removed packages are not lost in our data model, we simple don't show them in the UI. Once we allow package browsing to include removed packages (where the users could download them) the need of a special component/pocket will become obsolete (it is already controversial). I will keep this report as a triaged bug for 1.1.12, at that point we will have time to actually look and hopefully fix it.

When addressing this bug, please include support for the following use cases:

1) Alice discovers that badpackage is no longer useful, as it has been superceded by newpackage for the past couple releases. Alice marks the package for removal from the archive, whereupon it is no longer distributed as a source or binary package for the current development release or any future releases. The package status should not appear in release status pages for the removal release or future releases.

2) Bob discovers that cruftpackage has a critical bug (public security exploit, possible data loss, creates system instability, etc.). Bob marks the bug as making the package not suitable for this release, whereupon it will no longer be distributed as a binary package for the current devlopment release unless there are reverse dependencies not labeled for removal. When the next development cycle is opened, cruftpackage is imported as source. There is a clear indication that the package is blocked for a specific release due to a critical bug in package and release status pages.

3) Chris has prepared a new revision of cruftpackage which closes the critical bug identified by Bob. The package is submitted for build, and restored to the current development release as both source and binary packages, without requiring appproval in the NEW queue at either stage. Note that "current development release" may have changed between Bob indicating the package is unsuitable for release and Chris addressing the issue.

4) Daryl is looking for something to do, and reviews the list of currently blocked packages with associated bugs. Daryl discovers that oldpackage has not been maintained in a while, and has a few release-blocking bugs. Daryl collects the new upstream, adds patches for the blocking bugs, and uploads to the archive.

    Case #1 above is a continuation of current practice. Cases #2-#4 introduce new functionality, intended to allow for better QA triage for leaf packages. Ideally support for #1 is maintained as distinct from support for Cases #2-#4, as packages removed under #1 are typically not suitable for reinclusion, and so should not be presented in Daryl's list.

Setting to "won't fix" because the right solution is to allow browsing of removed packages.

How does that help release coordination? Packages removed for RC bugginess should come back from the next autosync (unless they are in the special class of packages that are being removed from Debian anyway). Being able to browse these temporarily removed packages doesn't make it any easier to bring them back for the next release.

Theoretically all removed packages in launchpad could be ressurrect by a single click, there is no point to mess with pockets/component which embeds ubuntu policies just because you want to keep track of them.

We are already able to track deletions where they are as in 'last/all deletions in hardy' and them re-publish the packages involved in the same or another location.

It actually gets even easier if you consider that QA-related removals usually maps to bug (which you can easily track) then getting from the bug to the package might be trivial and then you only need the ability to re-publish the package.

Bear in mind that we already have PPA to help with primary archive development, for instance, lets say package foo was removed from hardy RC4 because it contained a lot of problem and Emmet know how to fix them, instead of pissing people off with patches and requests you simply visit package foo page and click on "Copy to my PPA" and do whatever you can to get the package in shape, once it is fixed, I sure archive-admin will be more than happy to accept it again.

Summing up, we have a lot of open possibilities, but none of them requires/involves having a new component or pocket.

That sounds reasonable. In the vast majority of cases, it's a matter of re-pulling from Debian, rather than a PPA, but if there are other mechanisms in place, there is no reason for another component or pocket. I am just concerned about packages being lost just because they weren't in a releaseable condition on some arbitrary date.

Right, don't get this 'won't fix' stamp wrong, your concerns are legit. Free to file a new bug requesting mechanisms for tracking, copying and re-publishing deleted packages as part of the QA tasks of a distroseries. Thanks for you feedback.