Gerfried Fuchs <rhonda@deb.at> writes: > Remove from stable-bpo if it's not expected to come back in is what we > actually do, yes. And to have an overview of these situations I created > myself the diffstats page: > http://backports.debian.org/wheezy-backports/overview/ > > Looking at the "not available" page, I noticed that I need to remove > the twisted-* packages. *heading over to franck* The only reason that this one shows up to be removed is because the package names changed in unstable/testing from twisted-* to python-twisted-* so I don't think that this should be removed. You might argue that a newer version from testing should be put into bpo and these removed, which I wont argue against, but updating the version in bpo From a new testing version should not be rushed due to this aggressive removal situation. Personally, I've found the aggressive removal from testing to be a shock in a number of cases. I understand the motivations behind it, but it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. I feel like the window for removal from testing is too short and is having negative consequences on the stress level of people whose volunteer labor contributions to Debian are already stretched thin. Most everyone I've spoken to in this situation has said that it wouldn't be so bad if they had just a couple more days. I'd like it if that shock wasn't also quickly passed on to backports and instead things were examined a little more closely before purging packages. For example, say package X has been backported at version 1.0, version 2.0 is uploaded to sid, transitions to jessie and then has an RC bug that threatens removal. The problem with the 2.0 package has to do with some security issue upstream, which looks like it will be a deep code massage to fix and will take a while, too long for the testing removal auto firing squad. The maintainer wishes that they had not uploaded 2.0 yet, because 1.0 was fine. Now backports sees the difference, because the 1.0 version has been removed from testing, so bpo now has a newer version than what is in testing. But the package is actually a *better*, but backports gets its package removed anyways. Maintainer decides to eat the epoch and re-uploads version 1.0 to get a functioning package, uploads urgency high and package transitions to testing and a backport of the same package needs to be done again in a very short period of time after it was removed. micah Churn baby churn, disco inferno!
Attachment:
pgpwdAsEePZDk.pgp
Description: PGP signature