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 <gregchiaraquartet.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
>
>

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php