Sean Whitton: > Hello, > > On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote: > >> On Wed, Nov 21, 2018 at 05:57:40PM +0000, Dimitri John Ledkov wrote: >>> Before we get there, we should first start autoremoving packages from >>> unstable, if we consider rc-buggy in unstable to be unacceptable. We >>> do have quite a bit of things in unstable, that are neither getting >>> fixed, nor getting removed. And are in this limbo state of "no longer >>> in testing.... no longer in stable.... no longer in old-stable... >>> still in unstable". >> >> I'm all for it. > > What harm are the packages doing sitting in unstable? Distributing them > does not have much point, but neither does removing them. >
Hi, Since most of our QA is based on unstable, it is hard to tell when some particular problem is *solved* when we got a number of extra packages in sid that are RC-buggy and that you can "ignore". Presumably this is an argument for having dedicated QA reports only for testing, so you can tell the state of a particular issue only for the next stable release. > If someone does want to come along and fix the package, having it pass > through NEW again is not a good use of ftpteam time. > Nothing is gratis. Currently, our archive-wide QA is paying the price by making it difficult to see when we can stop supporting deprecated features (or which packages to focus on to fix it). Plus our current garbage collection process for unstable is not gratis either on volunteer time. It involves someone identifying a package for removal and then asking the FTP team to spend time removing it. If we automated the removal here (with some trivial stop gaps for people in the situation you refer to), then we could save time from the FTP team and distribute it to the people actively working on the packages. ~Niels