[Dlang-internal] Regression control & breaking changes policies

[Dicebot via Dlang-internal]

On 12/07/2016 06:39 AM, Walter Bright wrote:
> 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.

We will get much better progress by slowing it down and improving
stability. It will be slower, but consistent. Right now D development
happens in a "1 step forward, 0.5 to 2 steps back" mode. Last two
releases were terrible.

Again - you can't do harm by reverting a problematic change. If problem
was not dire enough to make previous release unusable, it can always
wait for one release more. We can't scale to more contributors if
working with master branch requires knowledge of all half-broken changes
that were not reverted.

> 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.

And that is why I oppose so hard to your way of doing things. By attempt
to fix bugs we don't care about you are willing to straight up fuck our
working code that we do care about. It doesn't matter how much you make
things better if you also make things worse.

>> 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.

Well here is PR which does introduce regression. It exists in master for
months. It blocks further progress with syncing scope branch and master.
And yet you oppose reverting it. What is the point? You complain about
slow progress with dip1000 but your are also the main person putting
obstacles to move forward with it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/dlang-internal/attachments/20161212/6ed1e245/attachment.sig>