Currently in WIP because I haven't tested it yet.

Shouldn't we have an Appveyor job trying nmake clean? (or Travis trying make clean, for that matter?)

Couldn't we try to use wildcard deletes as much as possible? Deleting every single file separately is so painfully slooow on windows...

No. We do too much of that already. People who build in the source tree run too much risk of losing their work. We have already had that issue

I have also tried to solve that long line issue: #10895

This issue is in a state where it requires action by @openssl/committers but the last update was 30 days ago

@iamamoose Hmm, maybe reminding for PRs that still have a [WIP] tag is overzealous...

I wonder why my #10895 is being ignored, that is not WIP,
but I have not been testing that since weeks because I don't like to waste my time.

@iamamoose Hmm, maybe reminding for PRs that still have a [WIP] tag is overzealous...

It could certainly ignore things with WIP in the title, but would be better if the labels held the state, perhaps a WIP label?

The labels are not visible in the notification area, but the WIP prefix is.

And non-members can set the title, but they cannot set labels.

There's no reason for it to be WIP any more (hasn't been for a while)

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests. Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Have you also fixed the nmake distclean ?

And, why is everyone force-pushing after the approval ?
That means nobody can ever do

git fetch git://github.com/openssl/openssl.git refs/pull/11171/head:pr-11171-as-approved

to get the version as it was approved.
I know I can trust you, but you know it quite well, "Vertrauen ist gut, Kontrolle ist besser."

Its normally because a rebase is needed.

Yes, but then the rebase should be done, and a new approval requested.
But recently everybody started to rebase without any need, just to get the
gitbub icon that shows a merge. Everytime I merge one of my commits,
github says "unmerged commits" but I comment, that I merged the code
and close the PR. Even if my branch is deleted later what I dont do,
the pull request stays to be retrievable with above work flow.

And, why is everyone force-pushing after the approval ?

Everyone? I think that I've only seen me and @DDvO do this so far. Basically, it allows github to notice and to make that "Merged" status and notification for us.

I already asked @DDvO to stop doing that. Now I ask you.
We do not need to make github happy, github is optional.

It made me happy too, FYI. Also, it does make it clearer what PRs are closed because they were abandoned, which does happen for various reasons.

Okay, I made my point, just do what you want then.

When I merge a PR I always close with a comment that I merged it.
And due to the (Merged from https://github.com/openssl/openssl/pull/11425)
The merge commit appears in the history of the PR
(I only broke it once, when I had a typo in the addrev command,
and did not notice before pushing). I took precautions in my workflow
to make sure that cannot happen again.

When I merge a PR I always close with a comment that I merged it.

I also do this to make clear that I did not close the PR for other reasons.

And due to the (Merged from https://github.com/openssl/openssl/pull/11425)
The merge commit appears in the history of the PR

Well, the PR appears in the history of the master branch due to the Merged from ... line,
but the approved commits of the PR do not show show identically in the master
because the commit messages have been amended by reviewer and PR number info
and typically the commits have been rebased immediately before merging.