Am Sonntag, den 17.05.2020, 19:43 +0200 schrieb David Kastrup: > Carl Sorensen <[email protected]> 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.
+1 to all three replies.
signature.asc
Description: This is a digitally signed message part
