I'm reading the 7.0.4 NEWS file[1] and I get the policy of just writing
the bug number and headline, but in a lot of cases the bug report
headline says nothing about the actual problem, or the actual fix.
For instance:
Fixed bug #71559 (Built-in HTTP server, we can download file in web by
bug). (Johannes, Anatol)
Fixed bug #71474 (Crash because of VM stack corruption on Magento2).
(Dmitry)
Fixed bug #71443 (Segfault using built-in webserver with intl using
symfony). (Laruence)
Would it not be an idea to write what was fixed, instead of what was
broken?
[1] https://github.com/php/php-src/blob/php-7.0.4RC1/NEWS
--
Tom Sommer
I'm reading the 7.0.4 NEWS file[1] and I get the policy of just writing the bug number and headline, but in a lot of cases the bug report headline says nothing about the actual problem, or the actual fix.
For instance:
Fixed bug #71559 (Built-in HTTP server, we can download file in web by bug). (Johannes, Anatol)
Fixed bug #71474 (Crash because of VM stack corruption on Magento2). (Dmitry)
Fixed bug #71443 (Segfault using built-in webserver with intl using symfony). (Laruence)Would it not be an idea to write what was fixed, instead of what was broken?
No. IMO, it's good practice for change logs to describe the problem for fixes, and the change or addition for changes or additions.
Maybe for something like "php-fpm dumped core", the description can be expanded to include the reason ("php-fpm dumps core on SIGQUIT"), but that's much better than "Fix: call zend_signal_init() again on FPM startup", because it gives you no idea of what the problem was, which is important for users looking at (or searching through) changelogs to figure out if an update addresses a problem they're experiencing.
David
I'm reading the 7.0.4 NEWS file[1] and I get the policy of just writing
the bug number and headline, but in a lot of cases the bug report headline
says nothing about the actual problem, or the actual fix.For instance:
Fixed bug #71559 (Built-in HTTP server, we can download file in web by
bug). (Johannes, Anatol)
Fixed bug #71474 (Crash because of VM stack corruption on Magento2).
(Dmitry)
Fixed bug #71443 (Segfault using built-in webserver with intl using
symfony). (Laruence)Would it not be an idea to write what was fixed, instead of what was
broken?No. IMO, it's good practice for change logs to describe the problem for
fixes, and the change or addition for changes or additions.Maybe for something like "php-fpm dumped core", the description can be
expanded to include the reason ("php-fpm dumps core on SIGQUIT"), but
that's much better than "Fix: call zend_signal_init() again on FPM
startup", because it gives you no idea of what the problem was, which is
important for users looking at (or searching through) changelogs to figure
out if an update addresses a problem they're experiencing.David
--
What worries me is when memory corruption bugs are published in the RC#
changelog before the fix is available. That could bite us one day.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
What worries me is when memory corruption bugs are published in the RC#
changelog before the fix is available. That could bite us one day.
Do you have examples? I do not see how the NEWS entry can be added but
the fix has not been merged.
Also security issues handling as a whole is a different important discussion :)
--
Pierre
@pierrejoye | http://www.libgd.org