On Mon, Feb 29, 2016 at 9:30 AM, David Zuelke <dz@heroku.com> wrote:
> On 28.02.2016, at 13:24, Tom Sommer <mail@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
>
>
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/>
