On 28.02.2016, at 13:24, Tom Sommer <m...@tomsommer.dk> wrote:
>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
