Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91461
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6FDCB900-E0AC-47D4-9B69-491441ED32CF@heroku.com>
References: <e9ca8048ffc2fc25e908247c0f366dc9@tomsommer.dk>
	<6FDCB900-E0AC-47D4-9B69-491441ED32CF@heroku.com>
Date: Mon, 29 Feb 2016 12:40:45 -0500
Message-ID: <CAKws9z1KdeC21SaWPHFYQjktas0sVT9ir0n=8qhVSXOu_uxuEA@mail.gmail.com>
To: David Zuelke <dz@heroku.com>
Cc: Tom Sommer <mail@tomsommer.dk>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1137a378072be8052cec26f6
Subject: Re: [PHP-DEV] NEWS entries
From: scott@paragonie.com (Scott Arciszewski)

--001a1137a378072be8052cec26f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 headlin=
e
> 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 figur=
e
> 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
>
>
=E2=80=8BWhat worries me is when memory corruption bugs are published in th=
e RC#
changelog before the fix is available. That could bite us one day.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
=E2=80=8B

--001a1137a378072be8052cec26f6--