Carl Sorensen <carl.d.soren...@gmail.com> writes: > 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.
Seems appropriate here. > 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. I don't think reopening makes a lot of sense: I'd also open a new issue here and post a reference to the new issue, possibly with a note which version is affected from the revert. Ongoing information then in the new issue. > 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. New issue + crossreference would be my suggestion. -- David Kastrup