I don’t believe there are a lot of issues that are fixed but not closed. On release, our process is to find all fixed issues and move them to closed status. If there are fixed issues that are older than one release, show me a Jira report.
If a commit does not fix an issue but merely adds a test case, the commit message should be something like ’Test case for [CALCITE-xxxx]’. Look through the git log to see what people have done in the past. Ideally there will be one commit per issue. Endeavor to include test cases, and documentation, and anything else, in the commit to make the fix complete and self-contained. But the relationship is not strictly one-to-one. Sometimes there will be more than one commit for an issue (say if you realize too late that you missed a test case, or you have to back out a fix). And some commits don’t have a corresponding Jira case (say if they fix a typo or a non-user-visible bug). Just try to make the commit message as useful as possible, given that people will be reading it in ten years in the git log and release notes. If distinct commits have different purposes, I don’t see how they could usefully have the same commit message. Julian > On Jan 25, 2026, at 10:32 PM, Mihai Budiu <[email protected]> wrote: > > If there was a small number of issues, doing a more thorough cleaning job > would make sense, but I'd rather spend our brain energy in fixing real > issues than tracking commits which closed an old one. In an ideal world the > person who opened the issue would make some of the work required for closing > it too. > > The process you have been following so far looks great to me. > > Mihai > > ________________________________ > From: jensen <[email protected]> > Sent: Sunday, January 25, 2026 7:43 PM > To: [email protected] <[email protected]> > Subject: How to handle JIRA tickets that have been fixed but not closed > > Hi Calcite Community, > > > Since Calcite has been around for a long time, many JIRAs have actually been > fixed but not closed [1]. Now, I'd like to discuss how we should handle these > JIRAs. For example, should we submit an additional PR to provide test cases > to prove that the JIRA has been fixed? Should we find a commit that directly > or indirectly fixes the issue as additional information (this may not be > mandatory)? > > > If we need a PR, do we need some minor specifications? For example, should we > still maintain strict consistency between the PR title/commit message/jira > title? Should we include the commit that fixes the issue (if found) in the PR > and explain that this is just adding test cases? So, I'd like to ask how we > can better handle these types of JIRAs. > > > > Best regards, > > Zhen Chen > > > > > [1] https://github.com/apache/calcite/pull/4763
