On Thursday, 22 November 2018 at 11:55:14 UTC, Daniel N wrote:
> "impossible to review" is a very strong statement, how then were you able to write the spec?

I guessed, well, I wrote it the way I think what he has done ought to work.
Hence why Walter needs to review it.

> I had no issues understanding what Walter meant both comments and the test cases speak for themselves, he also offered to answer any questions.

#8504 is not so bad #8408 on the other hand...

> If there is any corner case which you don't understand, it would imho be more constructive to ask him to add a new test case for it in #8504 so that any ambiguity will be cleared, future regressions prevented and coverage improved. It's very easy to misunderstand a written explanation, but code can only be interpreted one way. This is even more so for an international project where not everyone is a native English speaker.
>
> In my world the spec/doc/changelog is just a release blocker for the next official external compiler release, but by all means merge them simultaneously, now that they both are available.

The second issue at play is that there have been a number of undocumented changes to dip1000, and those changes were pulled on the understanding that it will be documented. That hasn't happened yet, and won't until Walter approves the documentation (it won't merge due to some weird LaTeX errors in the doc builder but that is beside the point).

On Thursday, 22 November 2018 at 12:32:30 UTC, Nicholas Wilson wrote:
>
> The second issue at play is that there have been a number of undocumented changes to dip1000, and those changes were pulled on the understanding that it will be documented. That hasn't happened yet, and won't until Walter approves the documentation (it won't merge due to some weird LaTeX errors in the doc builder but that is beside the point).

Well, my proposal is that we instead are strict about documentation being hard release blockers for the next release.

That approach would facilitate core-devs to work efficiently in between releases, not wasting resources on rebasing multiple times for many months or years(looking at you multiple this).

It's much easier to rebase old docs, than to rebase old code commits when internal API:s were refactored.

On Thu, 22 Nov 2018 12:32:30 +0000, Nicholas Wilson wrote:
> On Thursday, 22 November 2018 at 11:55:14 UTC, Daniel N wrote:
>> "impossible to review" is a very strong statement, how then were you able to write the spec?
> 
> I guessed, well, I wrote it the way I think what he has done ought to
> work.
> Hence why Walter needs to review it.

In other words, you need the spec PR to demonstrate intent. The most you can get from reviewing the dmd PR is that the code does something that seems reasonable on the face of it and probably won't blow up in anyone's face too much.

On Thursday, 22 November 2018 at 16:35:15 UTC, Neia Neutuladh wrote:
> On Thu, 22 Nov 2018 12:32:30 +0000, Nicholas Wilson wrote:
>> On Thursday, 22 November 2018 at 11:55:14 UTC, Daniel N wrote:
>>> "impossible to review" is a very strong statement, how then were you able to write the spec?
>> 
>> I guessed, well, I wrote it the way I think what he has done ought to
>> work.
>> Hence why Walter needs to review it.
>
> In other words, you need the spec PR to demonstrate intent. The most you can get from reviewing the dmd PR is that the code does something that seems reasonable on the face of it and probably won't blow up in anyone's face too much.

There is a big difference between:
a) Sorry, *I* am not able to review this but maybe someone else can?
b) Adding a Label which prevents everyone from reviewing/pulling.
(At least I normally don't even look at blocked work, since then PR probably needs to be updated in the future and then anyway reviewed once again...)