PHP PEAR Questions and Answers - Re: [PEAR-QA] Deprecation Handling RFC

Author

Re: [PEAR-QA] Deprecation Handling RFC

Klaus Guenther

2004-06-04, 3:57 pm

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.

Daniel Convissor

2004-06-04, 3:57 pm

Hi Tomas, et al:

Thanks for drafting this. Here are a few comments...

On Fri, Jun 04, 2004 at 02:09:05PM +0200, Tomas V.V.Cox wrote:

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

Users will still have these files laying around on their machines.
Similarly, people will come across old web pages or talk to people about
the package. They should be able to easily learn about that package and
of it's deprecated status. Therefore, I think it's important to leave the
items in the listings, though have a notice in the listing saying that it
is deprecated and which package has taken over. Also, the link from the
package info page should have the CVS link include "sa=1" in the query
string so the "hidden" files get shown.

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

No. Doing so will cause confusion.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Martin Jansen

2004-06-04, 3:57 pm

On Fri Jun 04, 2004 at 02:0905PM +0200, Tomas V.V.Cox wrote:
> - No package maintance in one year (CVS commits and releases)

There are surely a lot of packages that do not require any bug fixes
over a long time. Deprecating them is just silly.

> - Modify pearweb database and code for deprecated flag

I have a patch that implements this partially. If there is any
interest, just drop a mail.

--
- Martin Martin Jansen
http://martinjansen.com/

Tomas V.V.Cox

2004-06-04, 3:57 pm

Martin Jansen wrote:
> On Fri Jun 04, 2004 at 02:0905PM +0200, Tomas V.V.Cox wrote:
>
>
>
> There are surely a lot of packages that do not require any bug fixes
> over a long time. Deprecating them is just silly.
>

Please read my list of requirements with AND's not OR's :-)

>
>
> I have a patch that implements this partially. If there is any
> interest, just drop a mail.

I see no problem in just commiting it.

Tomas V.V.Cox

Sponsored Links