andygrove opened a new issue, #5925: URL: https://github.com/apache/datafusion-comet/issues/5925
## Problem Triage records how bad a bug is but not whether it is new. A defect that shipped in the last release and one introduced since it read identically on the issue tracker, even though the second one hits users who upgrade without changing anything on their side. There is no label for that distinction and no documented procedure for establishing it. A pass over the 19 open `priority:critical` issues, each checked against the `1.0.0` tag, found 18 pre-existing and one regression (#5783). That one was only identifiable by building the tag and running the reproducer: `1.0.0` failed loudly on a struct with byte-identical duplicate Parquet field names, and `main` silently returns 6 rows where Spark returns 3, because #5602 removed the `assert_eq!` guard that used to catch it. ## Proposal - Add a `regression` label for a bug that did not affect the most recent release. - Document in `docs/source/contributor-guide/bug_triage.md` how to establish regression status, resolving the comparison point from the release tags at triage time rather than hard-coding a version, and comparing against the tag's commit date rather than the release's publication date. - Order the evidence steps cheapest-first: issue creation date, then the implicated code at the tag, then whether the path was reachable at all, then building the tag and running the reproducer. - Treat `regression` as orthogonal to priority and as an escalation trigger. - Add the matching step to the `bug-triage` skill so automated passes apply it and report it. Two cases worth writing down, both of which came up in the pass: - Issues found during PR review routinely say "this is pre-existing, not caused by this PR". That is a claim about the pull request under review, not about the last release. - A query that failed loudly on the release and now returns silently wrong data is a regression, even though it never produced the right answer on either version. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
