[dmd-internals] Implementation change without matching spec change

[Daniel Murphy via dmd-internals]

It works here too.  If you recall the way I did ddmd, I made a giant
pull request and added hundreds of commits until it was working.  I
then rebased that into hundreds of pull requests and got them merged
one by one.  This meant there was both a PR complete enough to
actually see if it worked, and PRs small enough to be reviewed
individually.

The giant PR was never supposed to be pulled, and it never was.  It
existed so that:
1. I wasn't constantly blocked by PR review
2. A complete picture of the changes was available
3. Changes could be fleshed out and evaluated before landing in master

If working on the spec incrementally is hard, don't do it.  Finish the
work in a branch, write the spec, then break the work into small
reviewable PRs.


On Tue, Jun 28, 2016 at 5:40 AM, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 6/27/2016 5:24 AM, Daniel Murphy wrote:
>>
>> As usual Walter, the answer is to not push incremental changes to
>> master but instead to develop them in a branch.
>
>
> Small changes are easier to review. Large ones don't get reviewed at all, or
> get nitpicks like bikeshedding over spelling, or somebody just holds their
> breath and pulls it.
>
> Maybe doing things as branches works in other organizations where people can
> gather in the conference room and go over it together, but I don't think it
> works for us where we work fairly independently in multiple timezones.