Re: [PEAR-QA] A 'graveyard' for packages / unloved packages

>
> A quick note, moving packages to another channel is currently not supported
> in PEAR, in terms of, people are not auto migrated over. This would cause
> problems for people.
>
> - Helgi
>
> Apart from that hurdle, what do people think of
http://graveyard.pear.php.net/ ?

You'll have to add in a hosts file entry (38.108.46.133
graveyard.pear.php.net) ; because I have NFI how to do DNS entries.


The process for 'graveyarding' a package is a bit involved at the moment:

   1. Grab code - svn co http://svn.php.net/repository/pear/graveyard
   2. Grab the deprecated code, and if needed edit the package.xml until
   it's valid package 2.0
   $ pear convert package.xml
   3. Roll a new release with appropriate change log notes
   $ pfm
   4. Edit the channel to be graveyard.pear.php.net
   5. $ pear package
   6. $ pear svntag package.xml
   7. Regenerate the channel with pirum
    $ php pirum add Foo_Bar-1.2.3.tar.gz
   8. Commit the lot
   svn commit -m "Held funeral for Foo_Bar - proud father of Foo_Bar2"
   9. Pull an svn update on sg1
   sudo svn up /var/www/html/graveyard
   10. Remove the package from SVN
   $ svn rm Foo_Bar && svn commit -m "Buried Foo_Bar"
   11. Check packages-all for entries, and remove them
   $ svn propedit svn:externals packages-all
   12. Edit the package in pearweb, to indicate it's moved to another
   channel - superceeded flag if not already used? A link in the description
   text? Remove all old releases? Remove the entire package from pearweb?

As much as I like killing off crufty old code, many steps which only a
select few have the svn karma, relevant access, etc to do probably isn't a
long term solution.

What could we automate out of this lot? What should we do for a step 12?