Deprecation Handling RFC

Hi, Some thoughts on how to handle deprecation (with "drop" I mean deprecation): 1) Requirements for being dropped: - No reachable maintainer or agreement from him - No package maintance in one year (CVS commits and releases) - Lots of bugs open (a rule of > 2 bug each 10,000 downloads), this point is optional, only increases the chance. - Drop should only happend when there is a healty "competitive" package (reachable maintainers who attends at least bugs) 2) How dropping will be done: - Final try to contact current maintainers, waiting 1 month - Announce of the drop at the package home, telling its future destiny and the alternative, for let's say 2 months - After that, the package won't longer appear at package browser or search, neither at "pear/" CVS dir. 3) What work will gives to support dropping: - Create a system for the announce - Modify pearweb database and code for deprecated flag - Remote methods "pear list-all, pear seach" for deprecated flag - Create an infrastructure for deprecated packages at pearweb and a place in CVS 4) The questions on the air are: How drecated packages will be avaible? (at the web and cvs) Who will decide if a package should be dropped or not? Who will flag a package as deprecated? The name of a deprecated package could be taken in the future? Just pointing out that we can't just remove arbitrarily packages because of a social heating ;), there are developers and users behind those packages. Tomas V.V.Cox