Thank you for your replies, Mihai and Julian. Indeed, there aren't many JIRAs like this, but there are some. For example, the JIRA involved in the current PR is CALCITE-6504[1]. In this JIRA, it is mentioned that it has been fixed by CALCITE-5638[2]. However, CALCITE-6504 is not closed, and there are no related PRs. Now, the PR[3] has added related tests to verify this JIRA, so I would like to ask whether this type of JIRA should use the JIRA title to name the PR title and keep it consistent with the commit message. Or should we use "Test case for [CALCITE-xxxx]" to name the PR title in the future and then close the related JIRA? This type of problem usually occurs in scenarios where two JIRAs seem unrelated at first glance, but there are indeed some internal connections that need to be carefully studied to find out. People may only focus on one and leave the other behind.
Best regards, Zhen Chen [1] https://issues.apache.org/jira/browse/CALCITE-6504 [2] https://issues.apache.org/jira/browse/CALCITE-5638 [3] https://github.com/apache/calcite/pull/4763 ---- Replied Message ---- | From | Julian Hyde<[email protected]> | | Date | 1/26/2026 15:40 | | To | <[email protected]> | | Subject | Re: How to handle JIRA tickets that have been fixed but not closed | 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
