1. This should be applied to PHP_5_2 (not big change and in no way can
break anything)
2. You can always simply put a short comment like "Fixed in CVS, needs
documenting" and reclassify the bug report as docu issue. There's no
need for some fancy shortcuts or such. Just tune your process..
--Jani
Arnaud Le Blanc wrote:
On Thursday 23 October 2008 08:54:19 Hannes Magnusson wrote:
On Wed, Oct 22, 2008 at 20:59, Arnaud Le Blanc <[EMAIL PROTECTED]> wrote:
lbarnaud Wed Oct 22 18:59:34 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src NEWS
/php-src/ext/sockets sockets.c
Log:
MFH: Fixed bug #46360 (TCP_NODELAY constant for socket_{get,set}_option)
http://cvs.php.net/viewvc.cgi/php-
src/NEWS?r1=1.2027.2.547.2.965.2.349&r2=1.2027.2.547.2.965.2.350&diff_format=u
Index: php-src/NEWS
diff -u php-src/NEWS:1.2027.2.547.2.965.2.349 php-
src/NEWS:1.2027.2.547.2.965.2.350
--- php-src/NEWS:1.2027.2.547.2.965.2.349 Tue Oct 21 23:22:00 2008
+++ php-src/NEWS Wed Oct 22 18:59:33 2008
@@ -18,6 +18,8 @@
- Fixed bug causing the algorithm parameter of mhash() to be modified.
(Scott)
+- Fixed bug #46360 (TCP_NODELAY constant for socket_{get,set}_option).
+ (bugs at trick dot vanstaveren dot us)
- Fixed bug #46238 (Segmentation fault on static call with empty string
method).
(Felipe)
- Fixed bug #46205 (Closure - Memory leaks when ReflectionException is
thrown).
http://cvs.php.net/viewvc.cgi/php-
src/ext/sockets/sockets.c?r1=1.171.2.9.2.14.2.7&r2=1.171.2.9.2.14.2.8&diff_format=u
Index: php-src/ext/sockets/sockets.c
diff -u php-src/ext/sockets/sockets.c:1.171.2.9.2.14.2.7 php-
src/ext/sockets/sockets.c:1.171.2.9.2.14.2.8
--- php-src/ext/sockets/sockets.c:1.171.2.9.2.14.2.7 Tue Oct 21
23:39:15 2008
+++ php-src/ext/sockets/sockets.c Wed Oct 22 18:59:33 2008
@@ -19,7 +19,7 @@
+----------------------------------------------------------------------+
*/
-/* $Id: sockets.c,v 1.171.2.9.2.14.2.7 2008/10/21 23:39:15 lbarnaud Exp $
*/
+/* $Id: sockets.c,v 1.171.2.9.2.14.2.8 2008/10/22 18:59:33 lbarnaud Exp $
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
@@ -661,6 +661,9 @@
REGISTER_LONG_CONSTANT("SO_ERROR", SO_ERROR,
CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SOL_SOCKET", SOL_SOCKET,
CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SOMAXCONN", SOMAXCONN,
CONST_CS | CONST_PERSISTENT);
+#ifdef TCP_NODELAY
+ REGISTER_LONG_CONSTANT("TCP_NODELAY", TCP_NODELAY, CONST_CS |
CONST_PERSISTENT);
+#endif
I have cried so many times.
Does anyone have any idea how we can help docwriters find commits that
need to be documented?
Personally I would like _all_ changes in functionality, new stuff and
removed stuff to be attached to an bug report which then gets turned
into a documentation bug report referencing the commit and preferably
with a quick explanation from the developer on what changed including
an example of usage.
That would mean whenever you close a bug report you would get an extra
step, asking if "the fix needs documenting" which would require answer
and filling in the comment field before the report could be closed.
That at least forces you to think, which the [DOC] tagging did not
(and is probably the reason why it failed) and makes it 100% times
easier for doc guys to do their work.
-Hannes
Hi,
Sorry, I did not think to add a [DOC] tag in the commit message.
That would mean whenever you close a bug report you would get an extra
step, asking if "the fix needs documenting" which would require answer
and filling in the comment field before the report could be closed.
+1 :)
Or at least something like "Convert to Documentation bug" close the the
"Submit" button on the bug form. Also, CC-ing the phpdoc mailing list while
creating a "Documentation" bug, or while closing a "Feature request" bug.
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
