[dmd-internals] Implementation change without matching spec change

[Walter Bright via dmd-internals]

On 6/27/2016 5:40 AM, Михаил Страшун via dmd-internals wrote:
> There are always ways to address it. For example, creating aggregated
> spec change PR with checklist referring to dmd/phobos implementation PRs
> and modifying iteratively. Or preparing big chunk of related changes in
> separate upstream branch as Daniel has suggested.
>
> It is state of mind issue, not a technical one. Once ones mind is set
> strict to fulfill certain contribution criteria, it won't take a long
> time to find appropriate pattern to do so. The trick is to suppress
> inherent programmer laziness and actually start looking for that pattern
> by straight out declaring compromise/exceptions unacceptable.
>
> This is a typical short-term benefit vs long-term benefit choice
> scenario. Making small compromises to make ones daily work more
> convenient and productive may seem reasonable but it usually harms
> product health in the long term, the worse so the more people work on it.
>
> I am pretty sure whatever issue or inconveniences you may have,
> community will be able to suggest workflow of comparable convenience but
> without as high maintenance risks.

In a way, adding action items to bugzilla is doing the checklist, albeit in a 
different order. I know I rely heavily on bugzilla, often adding things myself 
as checklist items.

Also, it's often the case that a design change looks great, but comes unglued 
when it is tried in implementation. (C++ has been burned a couple times by 
accepting spec changes that nobody had implemented yet.)

The way C++ progress works is much more process oriented than we are, but they 
have a lot more people working on it than we do. I think you are quite correct 
in the value of the process for a larger organization, but we're still a pretty 
small group of core developers.

Doing things in branches works better for larger organizations. For small ones, 
like us, doing things in branches means it will get essentially zero testing, 
because everyone will wait until it is done before even looking at it. We just 
ran into that issue with the SafeInt thing.

As our organization has grown, we have added process here and there as it became 
clear it was strongly needed. I'm reluctant to preemptively add process, though, 
before it is an obvious problem.

tl,dr: Larger organizations need more process, but more process needs a larger 
organization to support it.