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