Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
hi Philip, Thanks for the clarification :) Cheers, 2010/8/6 Philip Olson phi...@roshambo.org: While hosting code within the PECL SVN repository has its advantages, I don't think one of them should be the 'ability to have documentation at php.net' and instead we, the documentation team, should adhere to what's listed at pecl.php.net. Users mostly care about 'pecl install foo' which is what we document. So if extensions like XDebug, Mongo and Memcached want to host sources elsewhere then so be it, but they are listed at pecl.php.net so can (and should) be documented at php.net. The VCS landscape has changed, so let's accept it. Also, I think it's far worse to scatter documentation all over the Internet which is something PEAR is suffering from today. Regards, Philip -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
While hosting code within the PECL SVN repository has its advantages, I don't think one of them should be the 'ability to have documentation at php.net' and instead we, the documentation team, should adhere to what's listed at pecl.php.net. Users mostly care about 'pecl install foo' which is what we document. So if extensions like XDebug, Mongo and Memcached want to host sources elsewhere then so be it, but they are listed at pecl.php.net so can (and should) be documented at php.net. The VCS landscape has changed, so let's accept it. Also, I think it's far worse to scatter documentation all over the Internet which is something PEAR is suffering from today. Regards, Philip
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
Just a PEAR-nut perspective here, because we deal with this exact issue. 2010/8/6 Philip Olson phi...@roshambo.org: Also, I think it's far worse to scatter documentation all over the Internet which is something PEAR is suffering from today. We also suffer from scattered source code — http://pear.php.net/bugs/bug.php?id=17646 I can think of a few instances where I've had to go to the waybackmachine to grab external docs, or dump the last release .tgz into cvs/svn.php.net because the external source was gone. This is a major issue we deal with frequently, especially with the size and age of PEAR. I would say, as long as the source, including docs, are maintained on a reputable, publicly available (d)vcs which the QA team has access to, there shouldn't major issues that can't be overcome — and github really makes this easy. I think the others that have spoken up have a good perspective on this. Improving the integration and flexibility of the PECL/bugtracker systems so they can integrate with reputable external development methods is a good thing. And as Philip stated - The VCS landscape has changed, so let's accept it. -- Brett Bieber
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Aug 5, 2010, at 1:25 AM, Derick Rethans wrote: On Thu, 5 Aug 2010, Hannes Magnusson wrote: On Wed, Aug 4, 2010 at 22:59, Kristina Chodorow krist...@php.net wrote: kristina Wed, 04 Aug 2010 20:59:18 + Revision: http://svn.php.net/viewvc?view=revisionrevision=301862 Log: mongo extension is now maintained on github Hmh. There is one quite large consequence of not maintaining the extension in PECL: The docs. http://php.net/manual only documents things that is within our SVN and control. That effectively means; if you don't want the ext in PECL anymore, the docs will have to be removed too. The extension however was never maintained in PECL in the first place, but always on github. It was always a code dump that sadly wasn't kept up to date. I'd also rather see the extension maintained in PECL though, as that's where it IMO belongs. Not sure where it belongs (as this is up to the developers) but this issue is showing up elsewhere too, like the memcached extension is now maintained at Github. I think there are others too. But if something is listed at pecl.php.net then it's a PECL extension, right? In which case, listing it within the PHP Manual is fine. So I think the question is more Is it a PECL extension? versus Where is the source code hosted? although this can easily be debated. Regards, Philip
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, 5 Aug 2010, Pierre Joye wrote: However I have more issues with extensions like xdebug when they use nothing but the web site to release their code. They should just create their own channel and that's it. And I would have done so if that possibility existed when Xdebug started. Xdebug is from 2003 (http://pecl.php.net/package/xdebug/1.2.0) but PEAR didn't have channels until 2005 (http://pear.php.net/package/PEAR/download/1.4.0). This is however not the issue at hand, which is the topic of having documentation in our manual of extensions not making use of our project facilities. Derick
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, 5 Aug 2010, Hannes Magnusson wrote: This thread is about mongo (with general explanation of how things work). Mongo uses nothing of the PHP infrastructure, other then maybe PECL packaging. They have external repo, bug tracker and support channels - just like xdebug. We have no control whatsoever over anything, and therefore cannot even pay attention to new features to document. We simply cannot have docs for extensions not maintain in our infrastructure. Well said, I agree with this; even though I feel a bit sad for the mongo driver's docs :) Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, 5 Aug 2010, Pierre Joye wrote: On Thu, Aug 5, 2010 at 12:37 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: We knew that when we accepted this extension and I have no problem with continuing to publish the mongo documentation. Or to be more clear, I see no reason to change anything in our policy right now. I have a big problem with it. This has been the policy for years. In the end, its the doc teams call (hence the CC). No it is not the current policy. It is the policy for the documentation (to be in php-doc's repo) but not for the code. It was never a requirement, not even the usage of a VCS is requirement. Perhaps it's time to write up a few of those guidelines? I obviously have little problem with having the mongo driver docs in phpdoc, but we do need to realize that we can't just have any random PHP extension's docs in phpdoc. For example, we probably don't want code-licence-incompatible extension's docs in phpdoc. (In that case, I could write a proprietary for-pay only extension and 'demand' those docs to be in the PHP Manual). So restricting it to PECL extensions that are installable through our pecl channel makes sense. (Because we demand certain licenses for those). Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 5:24 PM, Derick Rethans der...@php.net wrote: Perhaps it's time to write up a few of those guidelines? I obviously have little problem with having the mongo driver docs in phpdoc, but we do need to realize that we can't just have any random PHP extension's docs in phpdoc. For example, we probably don't want code-licence-incompatible extension's docs in phpdoc. php-doc policy is clear about that. Any doc must be under the CC license. So restricting it to PECL extensions that are installable through our pecl channel makes sense. (Because we demand certain licenses for those). That's what we do already (and why mongo and xdebug are fine). What Hannes seems to ask is that the code must be in svn.php.net and only pecl's tracker can be used. The latter is something I can imagine but as a complement to other trackers (like for mysql for example). For the code repository, I can imagine to restrict to svn.php.net, github and bitbucket. That should give enough options and we can nicely integrate each of these repos with our infrastructure (commits mail and tracker included). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, 5 Aug 2010, Pierre Joye wrote: On Thu, Aug 5, 2010 at 5:24 PM, Derick Rethans der...@php.net wrote: Perhaps it's time to write up a few of those guidelines? I obviously have little problem with having the mongo driver docs in phpdoc, but we do need to realize that we can't just have any random PHP extension's docs in phpdoc. For example, we probably don't want code-licence-incompatible extension's docs in phpdoc. php-doc policy is clear about that. Any doc must be under the CC license. Sure, you can still make docs CC-licensed for a very closed extension though. So restricting it to PECL extensions that are installable through our pecl channel makes sense. (Because we demand certain licenses for those). That's what we do already (and why mongo and xdebug are fine). What Hannes seems to ask is that the code must be in svn.php.net and only pecl's tracker can be used. The latter is something I can imagine but as a complement to other trackers (like for mysql for example). For the code repository, I can imagine to restrict to svn.php.net, github and bitbucket. That should give enough options and we can nicely integrate each of these repos with our infrastructure (commits mail and tracker included). Actually, I don't see why you want to restrict where the code is; as long as it is publically available (and not just a code dump once in a while). I would not be in favour of integrating other repositories either. Not because I don't like them, but because we can't just pick a few. There are many people, that have their own preferences about source control. I certainly don't want every extension's git commits (this is an example) end up on how pecl-cvs list. If they want the peer review, they can use php's SVN. If people want to use other trackers, fine; we have a link for that in the package info already. I don't see what other integration you want to do there. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 5:51 PM, Derick Rethans der...@php.net wrote: Sure, you can still make docs CC-licensed for a very closed extension though. So restricting it to PECL extensions that are installable through our pecl channel makes sense. (Because we demand certain licenses for those). That's what we do already (and why mongo and xdebug are fine). What Hannes seems to ask is that the code must be in svn.php.net and only pecl's tracker can be used. The latter is something I can imagine but as a complement to other trackers (like for mysql for example). For the code repository, I can imagine to restrict to svn.php.net, github and bitbucket. That should give enough options and we can nicely integrate each of these repos with our infrastructure (commits mail and tracker included). Actually, I don't see why you want to restrict where the code is; as long as it is publically available (and not just a code dump once in a while). I don't want to. Docs seem to be willing to have such restrictions. I would not be in favour of integrating other repositories either. I am in favor of nice integration to make the pecl platform a better place to host PHP extensions. The current situation is very obvious and clear, people does not like pecl because we don't provide what they need. I don't care about VCS related discussions but it is a good thing to provide alternative to SVN. github and bitbuckets are the leading tools of choice. And both github and bitbucket allow clean integration in any external tools (like pecl.php.net, trackers, snaps, builds, etc.). That's definitively something I'm willing to do. It is also not about good/choosen extensions but about being sure that we are attractive to new or existing developers. Right now we are not. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
