Re: 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?