Handling problems with patches after the patch is pushed

[Carl Sorensen]

Dear team,

I've been verifying issues from 2.21.1.

This has raised a need for clarification about how we handle issues
once they have been pushed.

Consider issue 5890: https://gitlab.com/lilypond/lilypond/-/issues/5890

The issue was fixed and a solution was pushed.

Then, Dan recognized that there was another warning that either showed
up in the patch or was not fixed by the patch.  So he posted an
excellent comment pointing out the problem.

So now, we have a situation where there is a closed issue with status
fixed, and a request for a change simultaneously.  I don't know how to
resolve this.

It seems to me that there are at least two possibilities for how this
should be handled.

1) Once an issue is accepted and pushed, if there are problems
resulting from the issue, a new issue should be created.  This lets
the original issue stand as fixed.

2) Once an issue is accepted and pushed, if there are problems
resulting from the issue, the patch should be reverted, the issue
should be reopened, and the comments should be added to the issue
discussion.

It seems to be unworkable to have a patch pushed to master but still
have comments on that issue saying the patch is bad, even if the issue
is reopened.  Because we now have a half-baked patch committed to
master, and we'll either have to add another patch (two patches to
resolve the issue) or modify the current patch (which has the
potential for merge conflicts if it takes a long time to get back to
it.

Every problematic commit I've seen as I've worked on verifying issues
for 2.20, 2.21, and 2.19 has resulted from adding comments after an
issue is closed.  I think we should have a policy asking that we
implement either 1 or 2 above.

Thanks,

Carl