This web page serves as an FAQ for the autoremoval mail sent 1 by the Release Team.
What is autoremoval?
The Release Team has a web page on it.
How do I prevent removal?
There are multiple items relevant to prevent removal depending on the issue:
- Triage the bug and ensure metadata is correct. E.g. if the bug is only affecting the version in unstable, then ensuring the BTS knows the right version prevents autoremoval for this issue.
- Fix the bug in unstable and ensure timely migration (keep an eye out).
- Downgrade the severity of the bugreport if the issue is not a release critical issue.
- If you are working on a solution, but the fix isn't ready yet, updating the bug with information will reset the timer (see below). It's OK to ping the bug to prevent autoremoval if there's work in progress related to solving the bug. That's true, even if that's happening outside of the package itself, but please ensure that's documented in the bug report, e.g. by using "blocked by" meta information, see also below.
- Ultimately you can also request the Release Team to tag the bug to be exempted from autoremoval, but that's typically weird for a bug of release critical severity.
What do I do when the RC bug is not in my package?
Obviously you can help fixing the bug in the (Build-)Dependency of your package.
- If you know or find a solution, provide patches or links to patches.
- Maybe the maintainer of the dependency could do with a co-maintainer, consider offering help.
- Maybe the dependency is unmaintained and needs to be salvaged.
- etc.
What are the timelines for removals?
It's all codified in the autoremoval calculation script, but being code, that's a bit rough as an answer. In words it's approximately the following2. Counting from the bug first appearance in the BTS, there is a delay of 14 before time starts ticking. Once the timer starts, leaf packages are scheduled for autoremoval after 15 days while packages with reverse dependencies and their reverse dependencies are scheduled for removal after 30 days. The timer is reset when there is activity in the bug report. Autoremoval emails are sent once a day for packages that are new on the list of scheduled removals.
During the freeze, bugs that are fixed in unstable and where the package has an unblock request or a migration hint will not cause autoremoval.
These timelines only apply to automatic removals
The release team can remove packages manually earlier than these timelines if they see the need for it. This is another reason why it is good to document progress on the bug even if it does not translate directly into a bug being fixed here and now as that makes the release team aware that you are working on a fix.
What happens if my package is auto-removed from testing?
It will be removed from testing. Outside of freezes, this is usually less of a problem, since as soon as the bug and any other testing blockers have been resolved, it can migrate back.
For freezes, it is important to stay diligent and resolve these issues in a timely manner. Depending on the stage of the freeze, the package might not be able to re-enter testing once removed.
To the best of my (PaulGevers) understanding (2)