Bug #61233 [Com]: xsl.security_prefs is not documented

From: Date: Tue, 29 Oct 2013 09:56:04 +0000
Subject: Bug #61233 [Com]: xsl.security_prefs is not documented
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-10556@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=61233&edit=1 ID: 61233 Comment by: os3476 at ithink dot ch Reported by: sixd@php.net Summary: xsl.security_prefs is not documented Status: Assigned Type: Bug Package: Documentation problem Operating System: All PHP Version: 5.4.0 Assigned To: chregu Block user comment: N Private report: N New Comment: @sixd - A patch to the way changes are obviously accepted in the PHP code base even if the corresponding documentation was not written. - ... - The package was changed to “Documentation problem”, so I don’t see the need to resubmit a report that will obviously result in a request for me to provide a patch again. - There was nothing antagonizing in my “I take it you don’t release code unless it includes the corresponding unit tests.”. It was actually an acknowledgement that I believe that patch submission is done properly with respect to tests. (really). - You forfeited your rights to not being antagonised by serving me the boilerplate “if you don’t like it, be constructive and submit a patch, it’s ok for people to be incompetent if they publish their source code” answer so dear to open source developers who have problems admitting it when they screw up, even though you’re not even a user of XSL, and definitely not involved in its development, and did log a bug to try and improve things. Previous Comments: ------------------------------------------------------------------------ [2012-10-22 07:21:01] sixd@php.net - Patch to what? - Doesn't seem constructive or concise - Anyway, that appears to be non-xsl related and so you should log another bug for it. - Antagonizing open source developers with comments like "I take it you don't..." is often going to be counter productive - Antagonizing someone who is not even a user of XSL, and definitely is not involved in its development, and who did log a bug to try and improve things (i.e. me) isn't going to help anything at all ------------------------------------------------------------------------ [2012-10-19 07:13:05] os3476 at ithink dot ch What about this? @@ -42,2 +42,2 @@ - When you introduce a new configuration option, set its in-code default value (when no value is given in any ini file) to the desired default value; + When you introduce a new configuration option whose desired default value breaks existing code, set its in-code default value (when no value is given in any ini file) to having no effect at all compared to the previous version, and add it with the desired default value to the php.ini.dist (or whatever you call it) file, so that people who upgrade see the new option and can anticipate the problems; + @@ -44,2 +44,2 @@ - When someone submits a patch that looks urgent because of security issues, accept it as quickly as possible. + When someone submits a patch, no matter how urgent it may seem to apply it, check if the corresponding documentation was written before accepting it; /* I take it you don’t release code unless it includes the corresponding unit tests. Documentation is the same. */ + @@ -46,0 +46,2 @@ + To that effect, make sure everyone who submits a patch know how they can be anonymously constructive about documentation as well; + @@ -46,2 +48,2 @@ - Provide online documentation for the latest version of PHP; + Provide a documentation archive, so that people can consult documentation that matches the PHP version they use and not just the latest that they likely can’t use because of their hosting provider, LTS Linux distribution, company policy or whatever reason; + There. That’s a constructive patch to your methodology that I’m submitting. Let me know when it makes it to the master branch. ------------------------------------------------------------------------ [2012-10-15 07:11:34] sixd@php.net @os3476 if the code/package author is unable to make a change for whatever reason, feel free to be constructive and help the PHP community by submiting a doc edit at https://edit.php.net/ Anonymous users can submit patches. ------------------------------------------------------------------------ [2012-10-15 06:57:16] os3476 at ithink dot ch Documented in the PHP documentation. You know, the web site where you go when something does not work… ------------------------------------------------------------------------ [2012-10-12 02:13:11] sixd@php.net From NEWS: - XSL: . Added xsl.security_prefs ini option to define forbidden operations within XSLT stylesheets, default is not to enable write operations. This option won't be in 5.4, since there's a new method. Fixes Bug #54446. (Chregu, Nicolas Gregoire) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61233 -- Edit this bug report at https://bugs.php.net/bug.php?id=61233&edit=1

« previous php.doc.bugs (#10556) next »