[Dlang-internal] Regression control & breaking changes policies

[Walter Bright via Dlang-internal]

On 12/6/2016 6:03 PM, Dicebot wrote:
> On a more serious note - not breaking things is much more important than
> fixing things. Even if existing issue is severe, the fact that it exists
> for a long time means users have a way to mitigate it. You can't make
> things worse by delaying it for one release. One the other hand, any
> issue that causes existing projects to break has sever consequence for
> ecosystem usability.

On the other hand, we cannot progress the language by freezing it. After all, 
one transitions to newer versions of the language for good reason. Furthermore, 
bugs (especially safety problems) can be a silent liability for any code that 
has them.

So, yes, delaying these sorts of fixes can most definitely make things worse for 
users.

This is why I push hard on these safety fixes. I want them fixed before they 
suddenly cost somebody on code they thought was fine.


> I am perfectly fine with "any rule must have exceptions approach". But
> there has to be at least some basic rule. Productivity of D development
> suffers from decision reluctance horribly exactly because there is no
> way to say if something non-trivial is OK to merge unless you come and
> say so.

I've approved a lot of PRs that turned out to cause regressions. I don't know of 
any way to prove that PRs do not introduce regressions. At least we have a test 
suite that gets continuously added to - that helps enormously.


> https://github.com/dlang/dmd/pull/6290 is perfect example of how absurd
> it gets. There was a simple task of reverting bunch of prematurely
> merged pull requests so that their implementation can be improved. Half
> a days job at most. And yet one month later we are still arguing and
> discussing and considering and doing nothing. How does it even surprise
> you after that scope PR doesn't get enough attention?

What surprises me is the reluctance to put it behind a switch.

 >type test7.d
struct A
{
     ~this(){}
}

@safe struct B
{
     A a;
}

 >..\dmd test7 -transition=safe
test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system 
destructor 'test7.A.~this'

 >..\dmd test7
test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system 
destructor 'test7.A.~this'

This is with my version of the code, which includes all of the scope related 
changes. One of the difficulties I have with all these branches is what the 
state of the code is in each. Arbitrary reversions make this situation even 
worse, making it much harder for me to figure out what the right fix is.

BTW, one of the difficulties is the change that stopped -transition=safe from 
setting -dip25. All of the scope changes were built on top of the dip25 changes 
- zero testing was done on setting those flags independently.

There are no reported issues with any of the other cases that PR dealt with, so 
I don't feel that throwing the whole thing out is the best way forward. The best 
way is to file bugzilla issues and take a look at if just a tweak would suffice.
-----------------------

The tangle of branches on this has reached a point where I suspect the best way 
forward is to simply abandon them, and I can submit a new PR that is the 
difference between master and what I have.