On Tue, 11 Nov 2014, Rebecca N. Palmer wrote: > Possible candidates: > a. Packages that work closely with hardware, where old versions > don't work with new hardware (example: beignet) > b. Packages that implement fast-evolving file formats or network > protocols, where you need the same version as the people you are > communicating with (possible example: jscommunicator [2]) > c. Packages that are generally rapidly improving, and are typically > used where this improvement is more important than stability
We used to have the volatile archive for software that absolutely needs to be updated very often (like virus scanners). We now have the "stable-updates" archive for this. https://wiki.debian.org/StableUpdates If packages are taking too long to go from stable-proposed-updates to stable-updates, that's something we could talk to the release managers about. Although, I am *sure* lack of widespread use (and therefore testing) of stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one of the reasons. However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. backports seem like a better solution for this case. However, we'd need to add further requirements: packages not built from the same source package cannot depend on such "never-for-stable" packages, and we must tag them somehow so that they never get released to stable... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141111173015.gb2...@khazad-dum.debian.net