[dmd-internals] Implementation change without matching spec change

[Daniel Murphy via dmd-internals]

As usual Walter, the answer is to not push incremental changes to
master but instead to develop them in a branch.

On Mon, Jun 27, 2016 at 8:10 PM, Walter Bright via dmd-internals
<dmd-internals at puremagic.com> wrote:
> Of course you have a great point. The trouble is, for me anyway, it's hard
> to write the spec incrementally. It also tends to make for a crummy spec. I
> find it easier and works better to take a more holistic view of spec
> updates.
>
> For example, I am currently working on the list of issues tagged with
> 'safe'. Many of them interact with each other. It's easier to work on them
> more or less in parallel when I have the 'context' of how that part of the
> code works in my head. The same goes for spec updates.
>
> But I don't want it overlooked, hence the shortcomings should all have
> bugzilla entries.
>
>
> On 6/27/2016 2:06 AM, Михаил Страшун via dmd-internals wrote:
>>
>> On 06/24/2016 09:14 AM, Walter Bright via dmd-internals wrote:
>>>
>>> All such issues should be files as bugzilla entries and marked with the
>>> 'spec' keyword.
>>
>>
>> This is fighting consequence and not a problem. Better approach would be
>> to have a simple checklist for all dmd/phobos mergers to follow:
>>
>> - Does this PR have tests?
>> - Does this PR have documentation?
>> - Does language spec and/or dlang.org articles need to be updated? If
>> yes, is there a PR for that?
>> - Does ths PR need changelog entry? If yes, is it there?
>>
>> If there is a failure on any of these points, PR must not be merged, no
>> exceptions or excused. Not even if it is written by you and desperately
>> needed by Andrei - for a simple reason that being too slow will never do
>> as much damage to the language as making bad quality changes.
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals