On Wednesday, 7 December 2016 at 01:56:15 UTC, Dicebot wrote:
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION

I couldn't agree more.

Compromising on "minor" regressions maintains the whole codebase in an unstable state, as there's no more guarantee that the feature I rely on today will not be "broken in a minor way" tomorrow to enable a "better" feature.

This is equivalent to disabling the tests that you've just broke to force your feature into the codebase (BTW allowing any kind of regression also make it a lot harder to guarantee that the codebase is actually improving).

Users have no global vision of the product, and if an update breaks their workflow, they will only see the regression. They won't be able to appreciate the fact that as a whole, the product might be better today. In one word, each time a compiler upgrade forces the users to modify their codebase, some of them leave (and god kills a kitten).

However, only simple policies stand the test of time ; if you want to establish a policy and need to argue over it, you've already lost the war.

The only regressions you might be able to forbid are the ones that are detected by an authoritative test suite that anyone can run before submitting patches, allowing to establish the brokenness of a feature in a non-ambiguous way.

It's a lot easier to enforce the authority of a test suite than a systematic-revert policy (with which I would totally agree!).

On Wednesday, 7 December 2016 at 04:39:52 UTC, Walter Bright wrote:
> 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.

This didn't work optimally because it's a mixture of the old approach to incrementally merging unfinished features (now spread over stable/2.072 and master/2.073) and transitioning the major part of the scope work to a feature branch.
We now have to live with some safety related changes already being released, but there really isn't much confusing about the branches, other than you using -transition=safe and Dicebot changing everything to deprecations.
So let's just resolve that argument and fix whatever branch differs from the outcome.

On Wednesday, 7 December 2016 at 04:39:52 UTC, Walter Bright wrote:
> 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, about half of the released regression could have been found by a slightly more extensive test suite including other code, hence https://ci.dawg.eu/job/projects/ (used to be green with 2.071.2).

On Wednesday, 7 December 2016 at 03:34:02 UTC, Walter Bright wrote:
> On 12/6/2016 5:54 PM, Dicebot wrote:
>> On 12/05/2016 03:10 AM, Walter Bright wrote:
>>> The table makes sense and looks right. But there's a problem with the
>>> return scope changes. It's just too much to just wholesale deprecate
>>> things all at once.
>>
>> It will need to happen at some point anyway. Without having those
>> deprecation implemented we can't even know how much existing code is
>> affected.
>
> That's the point of the flag. It can be done on the user's timescale, not ours.

Deprecations already provide for that. As a user you can delay updating a release for a short while, then you can still ignore or even silence deprecations until you have time to deal with them. That's the whole point of deprecations, they inform you than sth. is going to change and give you a timescale until when it needs to be fixed.
Hiding stuff behind a switch doesn't do much, but delaying the time until we inform people.
If you want provide a preview, we can build preview releases.

>>> People need time to ease into it, not be faced with
>>> a pile of diverse deprecation messages.

Maybe we could improve our deprecation output to classify the deprecation categories with some numbers, limit the amount of deprecations shown per category, and allow to silence specific deprecations.
The important difference, it's opt-out not opt-in, and doesn't add a pointless delay.

Also I doubt that anyone is using those switches.
Only found a 2 D user projects on github using DIP25.
https://github.com/search?l=Makefile&p=1&q=dip25&type=Code&utf8=✓
https://github.com/search?utf8=✓&q=dip25+extension:sdl+extension:json&type=Code&ref=advsearch&l=&l=

>> We can introduce `-preview=XXX` flag for that purpose but the key thing
>> is that it still has to use deprecations and not errors for all scope
>> related changes. Otherwise you introduce dangerous disparity between
>> what gets previewed and what will eventually become the default.
>
> I agree, but it doesn't have to be deprecations until the flag becomes the default.

That's just extra confusing. Also it doesn't work for dub, where one user might want to use that feature but a dependent library isn't yet compatible,
Again deprecations work as designed here (as in any other language) and it remains unclear why you need something different.

>>> Having -transition=safe makes that practical, and also ensures time to
>>> correct any unrecognized issues with it.

That's quality of implementation and our testing duty. Also since hardly anyone will test that switch, the main effect it has has is delaying the time until the issues pop up.

>> 1) `-transition` flag is not for this purpose. You want this behavior -
>> please introduce new flag group, for example `-preview=scope`. Desire is
>> legit but you have to use a different flag for such purpose.
>
> It originally was just `-safe`, but I got a lot of flak for that and pressure to use `-transition`. I don't really care what the flag is. It just needs a flag.
>
> I doubt users will really care either if it is -safe, -dip1000, -transition=safe, or -preview=safe.

Well -preview is really what this is about, but I'm convinced we're better off to provide preview releases/build instead of merging unfinished features into master and the next release.

On Wednesday, 7 December 2016 at 01:54:18 UTC, Dicebot wrote:
> Otherwise you introduce dangerous disparity

Please refrain from using exaggerating adjectives, they don't make your arguments better.

On 12/9/2016 9:06 PM, Martin Nowak wrote:
> On Wednesday, 7 December 2016 at 04:39:52 UTC, Walter Bright wrote:
>> 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.
>
> This didn't work optimally because it's a mixture of the old approach to
> incrementally merging unfinished features (now spread over stable/2.072 and
> master/2.073) and transitioning the major part of the scope work to a feature
> branch.
> We now have to live with some safety related changes already being released, but
> there really isn't much confusing about the branches, other than you using
> -transition=safe and Dicebot changing everything to deprecations.
> So let's just resolve that argument and fix whatever branch differs from the
> outcome.

The problem is I just don't know what is different between the branches, master, and what I have. The confusion about which bugs are fixed in which branch has also come up.

With a new PR based on what I have, things become straightforward. I can ensure the bugzilla issues are fixed and the autotester passes it and it all works with the latest Phobos.

On 12/9/2016 11:32 PM, Martin Nowak wrote:
> On Wednesday, 7 December 2016 at 03:34:02 UTC, Walter Bright wrote:
>> On 12/6/2016 5:54 PM, Dicebot wrote:
>>> On 12/05/2016 03:10 AM, Walter Bright wrote:
>>>> The table makes sense and looks right. But there's a problem with the
>>>> return scope changes. It's just too much to just wholesale deprecate
>>>> things all at once.
>>>
>>> It will need to happen at some point anyway. Without having those
>>> deprecation implemented we can't even know how much existing code is
>>> affected.
>>
>> That's the point of the flag. It can be done on the user's timescale, not ours.
>
> Deprecations already provide for that. As a user you can delay updating a
> release for a short while, then you can still ignore or even silence
> deprecations until you have time to deal with them. That's the whole point of
> deprecations, they inform you than sth. is going to change and give you a
> timescale until when it needs to be fixed.
> Hiding stuff behind a switch doesn't do much, but delaying the time until we
> inform people.
> If you want provide a preview, we can build preview releases.

Then preview it is.


>>>> People need time to ease into it, not be faced with
>>>> a pile of diverse deprecation messages.
>
> Maybe we could improve our deprecation output to classify the deprecation
> categories with some numbers, limit the amount of deprecations shown per
> category, and allow to silence specific deprecations.
> The important difference, it's opt-out not opt-in, and doesn't add a pointless
> delay.

Then we're still faced with reverting the deprecations, as what happened.


> Also I doubt that anyone is using those switches.
> Only found a 2 D user projects on github using DIP25.
> https://github.com/search?l=Makefile&p=1&q=dip25&type=Code&utf8=✓
> https://github.com/search?utf8=✓&q=dip25+extension:sdl+extension:json&type=Code&ref=advsearch&l=&l=

That's disappointing, but ok. It will take a while for us to explain how it works and get acceptance of it. The threads here are abundant evidence for that. But by getting it in, even under a switch, means we can make a credible case that D is a solution for memory safe programming, which is a huge deal.


>>> We can introduce `-preview=XXX` flag for that purpose but the key thing
>>> is that it still has to use deprecations and not errors for all scope
>>> related changes. Otherwise you introduce dangerous disparity between
>>> what gets previewed and what will eventually become the default.
>>
>> I agree, but it doesn't have to be deprecations until the flag becomes the
>> default.
>
> That's just extra confusing. Also it doesn't work for dub, where one user might
> want to use that feature but a dependent library isn't yet compatible,
> Again deprecations work as designed here (as in any other language) and it
> remains unclear why you need something different.

See above.


>>>> Having -transition=safe makes that practical, and also ensures time to
>>>> correct any unrecognized issues with it.
> That's quality of implementation and our testing duty. Also since hardly anyone
> will test that switch, the main effect it has has is delaying the time until the
> issues pop up.

True, but it's still the most practical way, given our large user base.


> Well -preview is really what this is about, but I'm convinced we're better off
> to provide preview releases/build instead of merging unfinished features into
> master and the next release.

It is finished. There are no known issues with it.

On Dec 10, 2016 12:00, "Walter Bright via Dlang-internal" < dlang-internal@puremagic.com> wrote:

On 12/9/2016 11:32 PM, Martin Nowak wrote:

Well -preview is really what this is about, but I'm convinced we're better
> off
> to provide preview releases/build instead of merging unfinished features
> into
> master and the next release.
>

It is finished. There are no known issues with it.


Since scope class are not testable, I wouldn't say it's finished.

On Saturday, 10 December 2016 at 09:08:53 UTC, Walter Bright wrote:
> The problem is I just don't know what is different between the branches, master, and what I have. The confusion about which bugs are fixed in which branch has also come up.

Easy as pie, we can merge master into scope and you're up to date with everything.
A feature shouldn't have anything to do with master, the fact that some scope work was already released, indeed complicates the situation a bit.

> With a new PR based on what I have, things become straightforward. I can ensure the bugzilla issues are fixed and the autotester passes it and it all works with the latest Phobos.

Please not, it creates the old deadlock that we cannot incrementally merge your work on that feature without risking a completely broken release. The only reason we could merge the first 2 chunks after a somewhat coarse review without extensive testing was the feature.

Please bear with me for a while, adopting a better git workflow will help us a lot to improve quality of releases and scale to more contributors.

Just a short summary of how feature branches are supposed to work atm.
This is not set in stone, so if you see improvements, please mention them.

- a feature is implemented in a single branch or multiple identically named branches across the dlang repos (dmd, druntime, phobos,...)
- testing and building is done using all of those branches
- the master branch is used as a fallback if one of the repos doesn't have a branch of the feature name
- Travis-CI, CyberShadow/DAutoTest, and the project tester (ci.dawg.eu) will work with feature branches, not sure if someone can manage to add support to the auto-tester
- once a feature is complete (implementation, docs, final testing+review), we merge the complete feature back into master, so it will be released soon after that

On 12/10/2016 6:14 AM, Mathias Lang via Dlang-internal wrote:
> Since scope class are not testable, I wouldn't say it's finished.

Please be more specific.