Re: Handling problems with patches after the patch is pushed

[David Kastrup]

Carl Sorensen <address@hidden> 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