Re: Deprecation Handling RFC

Tomas V.V.Cox wrote:

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)

Right now, according to QA discussions, such packages will be adopted by the QA team. Check the QA RFC for more information on QA powers. I think we rather need to focus on what constitutes sufficient reason to say that a package's lifespan is over. For example, if the functionality is widely available (e.g., HTML_Processor, which was simply an entity converter), we could send it to siberia once it's become a real moot issue. Else, deprecation is a much better state -- because there will be a lot of people who depend on a particular version (e.g., MDB) when a new version supercedes it (e.g., MDB2). It's not quite so cut and dry, because we need to ensure stability in PEAR. If someone has an application and comes to the PEAR website looking for information about the packages included, it would be a very negative thing if he couldn't find them -- even if we say, "yeah, you can use the commandline to install old junk." It certainly won't help PEAR's acceptance.

2) How dropping will be done: - Final try to contact current maintainers, waiting 1 month

In this case, I think it should be at least 2 months. Because if the poor guy's on vacation...

- Announce of the drop at the package home, telling its future destiny and the alternative, for let's say 2 months

2 months? you mean more like at least 6 months.

- After that, the package won't longer appear at package browser or search, neither at "pear/" CVS dir.

You really, really want to mess things up, don't you? Why do we have CVS if we throw away all the file history? I'm sorry, I'm -5 on this point. If you want to move the directories manually on the CVS server, that is quite another matter. But re-adding the files to a different location defeats the purpose of CVS. Also, if it is marked deprecated, it will still be available at /packages/<package>.

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

Sensible measures. But see my CVS caveat above.

4) The questions on the air are: How drecated packages will be avaible? (at the web and cvs)

Deprecated packages will be available as before, just not being listed. Let's put it this way: there's gotta be a difference between deprecated packages and siberia. Packages in siberia status should not show up anywhere in the listings, but should still be available if directly accessed.

Who will decide if a package should be dropped or not?

This is a QA matter, and the decision should be made in conjunction with the maintainer and the PEAR Group.

Who will flag a package as deprecated?

The QA team.

The name of a deprecated package could be taken in the future?

Yeah, but it could cause confusion. So if Net_IRC becomes deprecated and a new package is proposed, it should at least be forced to use Net_IRC2, etc. to prevent confusion.