Re: hosting packages on external VCS sites

-1 The current proposal leaves far too much room for interpretation -- what is the definition of "a substantial history as an external site" and how would you apply that policy without bias and hard feelings? I also don't understand how you would define a "registered domain name" if phpdoc.org counts but sourceforge.net does not. Where would coffeecode.net fall under these criteria? I really don't care about the RCS location because the uploaded releases provide a level of protection against the loss of external RCS repositories. There is no similar protection for the loss of external documentation (well, http://archive.org notwithstanding). Therefore, I would strongly support a proposal that package documentation must reside on pear.php.net. It's annoying to have to traverse different web sites with different navigational structures and widgets to pull together an application composed of a handful of different PEAR packages. If PEAR is to be a project based on common requirements, all of its documentation should be located in one place as well. The documentation is arguably the point where an entire project is sewn together. Dan On 18/03/07, Gregory Beaver <greg@chiaraquartet.net> wrote:

Hi all, I am dismayed to see that a few of our packages that have external hosting of revision control now come up as 404, and some with external documentation come up as 404. This is completely unacceptable. I would like to revise the requirements for allowing external hosting of PEAR package sources or documentation to read that this is only allowed if the package has a *registered domain name* and a substantial history as an external site. This would allow packages like phpDocumentor that have a large userbase outside of PEAR to operate under the assumption that the stability of a registered domain name means the site is not likely to suddenly disappear. This would mean that if a user is unwilling to host their code at cvs.php.net, we would no longer be willing to host their code at pear.php.net, and that external documentation is simply not allowed unless it is a manual at a registered domain name. By registered domain name, I mean something like "phpdoc.org" or "phpunit.de", not "joe.smith.uk" or even "sourceforge.net" Another possibility would be the immediate removal of a package from the maintainer's control should an external site go caput, rather than requiring a registered domain name. If either possibility is acceptable, this would immediately affect Structures_Graph, which has external documentation that is gone, Services_Google, which has missing external subversion, and probably a few other packages. I haven't gone through all 400+. What do you think? Greg -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php