Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91460
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heroku.com designates 74.125.82.42 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <e9ca8048ffc2fc25e908247c0f366dc9@tomsommer.dk>
Date: Mon, 29 Feb 2016 15:30:34 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <6FDCB900-E0AC-47D4-9B69-491441ED32CF@heroku.com>
References: <e9ca8048ffc2fc25e908247c0f366dc9@tomsommer.dk>
To: Tom Sommer <mail@tomsommer.dk>
Subject: Re: [PHP-DEV] NEWS entries
From: dz@heroku.com (David Zuelke)

On 28.02.2016, at 13:24, Tom Sommer <mail@tomsommer.dk> wrote:
>=20
> 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.
>=20
> For instance:
>=20
> 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)
>=20
> 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