[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
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. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
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. cheers, 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 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
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
hi, On Thu, Aug 5, 2010 at 10:18 AM, Hannes Magnusson hannes.magnus...@gmail.com 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. It is more the repository rather than the extension itself. More and more extensions repo have been moved to github to be able to enjoy git. But the releases are still done under pecl.php.net. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 10:42, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Aug 5, 2010 at 10:18 AM, Hannes Magnusson hannes.magnus...@gmail.com 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. It is more the repository rather than the extension itself. More and more extensions repo have been moved to github to be able to enjoy git. But the releases are still done under pecl.php.net. I suppose the definition of a 'PECL extension' if if its packaged and released on pecl.php.net (like xdebug for example). But we do have the problem though of not having access to the code if its not in PHP SVN, and therefore we cannot do anything when problems occur - and I think for that reason we cannot have the docs in the PHP manual (just like xdebug) :| There is a View Documentation link on the package page on pecl.php.net, which in the case of xdebug links to xdebug.org - and I think the same applies to this case. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
hi, On Thu, Aug 5, 2010 at 10:50 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I suppose the definition of a 'PECL extension' if if its packaged and released on pecl.php.net (like xdebug for example). But we do have the problem though of not having access to the code if its not in PHP SVN, and therefore we cannot do anything when problems occur - and I think for that reason we cannot have the docs in the PHP manual (just like xdebug) :| Why do you need to access the code? You can always report a bug if necessary. There is a View Documentation link on the package page on pecl.php.net, which in the case of xdebug links to xdebug.org - and I think the same applies to this case. I don't think so. And I'm also strongly considering to move some of my exts repo to github to make my work easier. It is also possible to better integrate github in pecl.php.net, but that's something I would like to investigate once I'm back to normal work :). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 10:58, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Aug 5, 2010 at 10:50 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I suppose the definition of a 'PECL extension' if if its packaged and released on pecl.php.net (like xdebug for example). But we do have the problem though of not having access to the code if its not in PHP SVN, and therefore we cannot do anything when problems occur - and I think for that reason we cannot have the docs in the PHP manual (just like xdebug) :| Why do you need to access the code? You can always report a bug if necessary. History tells us different. We cannot even reach many of the people who have code in our SVN - but we do have the possibility of fixing issues ourself because we have access to it. Also keep in mind that PECL extensions are often updated when the API in PHP changes drastically, and various people help out making sure they build on newer PHP versions. We cannot do that with extensions hosted outside of PHP SVN. We have never published docs from extensions not within our control in the passed, and doing that now will create a precedence for all the random extensions in the world wanting the same. We simply cannot do that. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 11:12 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Aug 5, 2010 at 10:58, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Aug 5, 2010 at 10:50 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I suppose the definition of a 'PECL extension' if if its packaged and released on pecl.php.net (like xdebug for example). But we do have the problem though of not having access to the code if its not in PHP SVN, and therefore we cannot do anything when problems occur - and I think for that reason we cannot have the docs in the PHP manual (just like xdebug) :| Why do you need to access the code? You can always report a bug if necessary. History tells us different. We cannot even reach many of the people who have code in our SVN - but we do have the possibility of fixing issues ourself because we have access to it. Also keep in mind that PECL extensions are often updated when the API in PHP changes drastically, and various people help out making sure they build on newer PHP versions. We cannot do that with extensions hosted outside of PHP SVN. We have never published docs from extensions not within our control in the passed, and doing that now will create a precedence for all the random extensions in the world wanting the same. We simply cannot do that. Very different topics are mixed in your reply. We never forced (and we decided to) to use php.net's repository. You said that docs have issues when the code is not in php.net's repo, but I don't see why in your reply Patches can always be sent via the bug tracker. 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. What prevents you to publish the docs for a doc when the code for the extension is not in php.net's repository? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 11:22, Pierre Joye pierre@gmail.com wrote: On Thu, Aug 5, 2010 at 11:12 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Aug 5, 2010 at 10:58, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Aug 5, 2010 at 10:50 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I suppose the definition of a 'PECL extension' if if its packaged and released on pecl.php.net (like xdebug for example). But we do have the problem though of not having access to the code if its not in PHP SVN, and therefore we cannot do anything when problems occur - and I think for that reason we cannot have the docs in the PHP manual (just like xdebug) :| Why do you need to access the code? You can always report a bug if necessary. History tells us different. We cannot even reach many of the people who have code in our SVN - but we do have the possibility of fixing issues ourself because we have access to it. Also keep in mind that PECL extensions are often updated when the API in PHP changes drastically, and various people help out making sure they build on newer PHP versions. We cannot do that with extensions hosted outside of PHP SVN. We have never published docs from extensions not within our control in the passed, and doing that now will create a precedence for all the random extensions in the world wanting the same. We simply cannot do that. Very different topics are mixed in your reply. We never forced (and we decided to) to use php.net's repository. You said that docs have issues when the code is not in php.net's repo, but I don't see why in your reply Patches can always be sent via the bug tracker. 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. What prevents you to publish the docs for a doc when the code for the extension is not in php.net's repository? 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. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 11:22, Pierre Joye pierre@gmail.com wrote: We never forced (and we decided to) to use php.net's repository. Ofcourse not. But if they choose to use our infrastructure they can use our infrastructure for docs too. If they choose to not do so, they effectively choose to not use our docs infrastructure. You said that docs have issues when the code is not in php.net's repo, but I don't see why in your reply Patches can always be sent via the bug tracker. However I have more And where should doc issues be reported? Are we supposed to pay attention to external bug tracker? Not gonna happen my friend, not gonna happen. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 11:44 AM, Hannes Magnusson hannes.magnus...@gmail.com 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 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. 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. If you want to force every pecl's project to use svn.php.net and pecl's bug trackers, then please make a proposal. For one, I would rather go (and will propose it) down the way to integrate external services like github and bitbucket with our infrastructures to be sure that PECL remains the place to be for PHP's innovations (it is not anymore). I don't have a problem either with projects using both pecl and external trackers (makes sense for daemon clients as some bugs may move from server to client). Howevere I do understand your feeling while looking at xdebug (but still has no issue). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 11:59, Pierre Joye pierre@gmail.com wrote: On Thu, Aug 5, 2010 at 11:44 AM, Hannes Magnusson hannes.magnus...@gmail.com 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 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). 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. If you want to force every pecl's project to use svn.php.net and pecl's bug trackers, then please make a proposal. I don't want to enforce it. But to get the docs in the PHP manual certain rules have to be followed, and this is one of them. For one, I would rather go (and will propose it) down the way to integrate external services like github and bitbucket with our infrastructures to be sure that PECL remains the place to be for PHP's innovations (it is not anymore). I'm definitely a +1 on that if done properly. I don't have a problem either with projects using both pecl and external trackers (makes sense for daemon clients as some bugs may move from server to client). Howevere I do understand your feeling while looking at xdebug (but still has no issue). Using external bug tracker for the extension and then our tracker for doc issues doesn't make sense. The doc team simply cannot follow random bug trackers. -Hannes
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
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
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. 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. If you want to force every pecl's project to use svn.php.net and pecl's bug trackers, then please make a proposal. I don't want to enforce it. But to get the docs in the PHP manual certain rules have to be followed, and this is one of them. I don't see what's the code has to do with the code. As long as the doc is in php-doc, what or where is the problem? I don't have a problem either with projects using both pecl and external trackers (makes sense for daemon clients as some bugs may move from server to client). Howevere I do understand your feeling while looking at xdebug (but still has no issue). Using external bug tracker for the extension and then our tracker for doc issues doesn't make sense. The doc team simply cannot follow random bug trackers. And does not have to. Reporting bugs to pecl.php.net's tracker works just fine and developers follow them. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 2:44 PM, Pierre Joye pierre@gmail.com wrote: I don't see what's the code has to do with the code. As long as the doc is in php-doc, what or where is the problem? with the ..doc.. :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
I was asleep for the first 12 hours of this discussion, but I really like having the mongo extension's documentation in the manual and I hope it can stay. I don't want to see the docs site buckle under its own weight or have the docs maintainers so overwhelmed that the documentation quality suffers, but I don't think that they can realistically maintain documentation for all of the extensions anyway, even with the commits going to one place. One (perhaps) comparable project is CPAN, where all of the developers maintain their own package's documentation, but it's all hosted on CPAN (so it can be done and does work). An alternative, if the doc team just wants easy access to the extension changes, is that I could do some sort of mirroring so that all of the git commits are forwarded to SVN. On Thu, Aug 5, 2010 at 8:44 AM, Pierre Joye pierre@gmail.com 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. 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. If you want to force every pecl's project to use svn.php.net and pecl's bug trackers, then please make a proposal. I don't want to enforce it. But to get the docs in the PHP manual certain rules have to be followed, and this is one of them. I don't see what's the code has to do with the code. As long as the doc is in php-doc, what or where is the problem? I don't have a problem either with projects using both pecl and external trackers (makes sense for daemon clients as some bugs may move from server to client). Howevere I do understand your feeling while looking at xdebug (but still has no issue). Using external bug tracker for the extension and then our tracker for doc issues doesn't make sense. The doc team simply cannot follow random bug trackers. And does not have to. Reporting bugs to pecl.php.net's tracker works just fine and developers follow them. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PECL CVS Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 15:06, Kristina Chodorow krist...@10gen.com wrote: I was asleep for the first 12 hours of this discussion, but I really like having the mongo extension's documentation in the manual and I hope it can stay. I don't want to see the docs site buckle under its own weight or have the docs maintainers so overwhelmed that the documentation quality suffers, but I don't think that they can realistically maintain documentation for all of the extensions anyway, even with the commits going to one place. That is totally true - and it is awesome that you have written the English docs - but did you know the docs have been translated to French? The Japanese version is even under development.. And whenever we make template changes, or just want to improve the markup, you get those for free. When people submit doc bug reports they expect the doc team to be able to solve it. I am not willing to go hunting around for random support forums and search for the location of the source to verify the report, and fix it. Things need to be under php.net if you want to use the doc infrastructure. You do have Documentation link on the PECL package website, which can point to external docs if you don't want it under php.net One (perhaps) comparable project is CPAN, where all of the developers maintain their own package's documentation, but it's all hosted on CPAN (so it can be done and does work). It is only a fraction of the (php) developers that write or put any sort of effort into their docs. As awesome that would be, its simply not how it works. An alternative, if the doc team just wants easy access to the extension changes, is that I could do some sort of mirroring so that all of the git commits are forwarded to SVN. And were are people supposed to report documentation issues? In your bugtracker or bugs.php.net? Where can I find devs to help me solve problems? How to I verify the extension hasn't been abandoned? Is it still experimental? Do we need to bump the version info? It is waaay to much hassle to work with things outside of our domain. If all the things around the extension is external, then your users expect to find the manual at your site anyway.. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
hi, On Thu, Aug 5, 2010 at 3:43 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: It is waaay to much hassle to work with things outside of our domain. If all the things around the extension is external, then your users expect to find the manual at your site anyway.. As I said already numerous times in this discussion: - the developers are available via the normal and standard way, the pecl's tracker, the mailing list and on IRC too for some of them - The developers read the bugs via the bug trackers too Alternatively I have no problem either to request the use of the pecl's bug tracker (if another one is also used, that's not a problem as long as pecl's tracker is allowed too). Doing so will minimize the pain for patch ore request submission. Now, if the php-doc team considers to stop hosting documentation for PECL's extension not having their repository in svn.php.net, then it is a rather drastic change and I have to think a bit further about the consequences of such changes in our policies. About users expecting everything to be at other location, my personal experience told me that they don't. They install an extension using 'pecl install foo' and then go to www.php.net/foo to find the doc (or via the TOC). 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 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
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, 2010-08-05 at 15:43 +0200, Hannes Magnusson wrote: That is totally true - and it is awesome that you have written the English docs - but did you know the docs have been translated to French? The Japanese version is even under development.. And whenever we make template changes, or just want to improve the markup, you get those for free. When people submit doc bug reports they expect the doc team to be able to solve it. I am not willing to go hunting around for random support forums and search for the location of the source to verify the report, and fix it. Things need to be under php.net if you want to use the doc infrastructure. You do have Documentation link on the PECL package website, which can point to external docs if you don't want it under php.net In a way this applies to the source as well. Having the master repository on php.net infrastructure enables the PHP developers at large to apply fixes to these extensions (like I did in http://news.php.net/php.pecl.cvs/13992 for instance, which even hit mongo) Additionally code on svn.php.net gets (some) review by other PECL contributors who can spot PHP-related mistakes. This in, my opinion, makes a key selling point for PECL at large.(*) On the other hand I can understand the interest in moving to a better (subjective) version control system and use a workflow offered by one of these tools. So in the end this comes down to: - Do we want PECL to be a place for approved good extensions or - Do we want PECL to be a place for all PHP extensions? johannes (*) Looking at this from the code perspective it kind of reminds me on the CLA discussions, they used our SVN server but didn't allow us to commit by our rules ...
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
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 15:59, Pierre Joye pierre@gmail.com wrote: Now, if the php-doc team considers to stop hosting documentation for PECL's extension not having their repository in svn.php.net, then it is a rather drastic change and I have to think a bit further about the consequences of such changes in our policies. I don't know where you are extracting phpdoc policies from, but since I have been involved with the project only docs for extensions that live within our domain and control are included in the PHP manual. Noone is policing commits to phpdoc, and those who have karma are trusted to follow the rules and guidelines of the project. -Hannes
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, Aug 5, 2010 at 6:09 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Aug 5, 2010 at 15:59, Pierre Joye pierre@gmail.com wrote: Now, if the php-doc team considers to stop hosting documentation for PECL's extension not having their repository in svn.php.net, then it is a rather drastic change and I have to think a bit further about the consequences of such changes in our policies. I don't know where you are extracting phpdoc policies from, but since I have been involved with the project only docs for extensions that live within our domain and control are included in the PHP manual. Noone is policing commits to phpdoc, and those who have karma are trusted to follow the rules and guidelines of the project. Hannes, Mongo is hosted on php.net, period. The code repository is another discussion which has nothing do to with php-doc. However if the php-doc team considers that the code must be in php.net too to allow the doc to be hosted on www.php.net, then we have a serious issue and we need to fix it. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
Hi! Also keep in mind that PECL extensions are often updated when the API in PHP changes drastically, and various people help out making sure they build on newer PHP versions. We cannot do that with extensions hosted outside of PHP SVN. With github it's supposed to be quite easy - fork it, make the change, issue the pull request. If the author does not merge it within reasonable time, people can always use your git tree instead. Also, can't we use git-svn integration to keep up-to-date copy in pecl SVN? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
[PHP-DOC] Re: [PECL-CVS] svn: /pecl/
On Thu, 2010-08-05 at 14:56 -0700, Stas Malyshev wrote: Hi! Also keep in mind that PECL extensions are often updated when the API in PHP changes drastically, and various people help out making sure they build on newer PHP versions. We cannot do that with extensions hosted outside of PHP SVN. With github it's supposed to be quite easy - fork it, make the change, issue the pull request. If the author does not merge it within reasonable time, people can always use your git tree instead. Also, can't we use git-svn integration to keep up-to-date copy in pecl SVN? The question is who owns the master repository. It's nice that I can branch and fix it while the maintainer ignores it and all users use the wrong branch (btw. my mongodb fix from my cleanup commit didn't reach github ...) johannes
