andygrove opened a new pull request, #5924: URL: https://github.com/apache/datafusion-comet/pull/5924
## Which issue does this PR close? Closes #. ## Rationale for this change Triage currently 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 today and no procedure for establishing it. This came out of a pass over the 19 open `priority:critical` issues, checking each against `1.0.0`. Eighteen turned out to be pre-existing. The one that was not — #5783 — was only identifiable by building the tag and running the reproducer, because the behavior change came from removing a `assert_eq!` guard in #5602: `1.0.0` failed loudly on a struct with duplicate Parquet field names, and `main` silently returns 6 rows where Spark returns 3. Nothing short of running it would have found that, which is why the procedure below ends where it does. ## What changes are included in this PR? A `regression` label, documented in `bug_triage.md`, plus the procedure for deciding it: - The comparison point is resolved from the release tags at triage time rather than hard-coded, so it moves forward on its own as Comet ships. It is the tag's **commit** date, not the release's publication date — `1.0.0` was tagged 2026-08-04 and published 2026-08-07, and commits landing in that window are not in the release. - The evidence steps are ordered cheapest-first: the issue's creation date settles most of the backlog for free, then reading the implicated code at the tag, then checking whether the path was reachable at all, and only then building the tag and running the reproducer. - `regression` is orthogonal to priority and is added as an escalation trigger rather than a priority of its own. Two traps are called out explicitly, 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 defect can be genuinely pre-existing relative to the PR that surfaced it and still have landed after the tag. - 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. That is exactly the #5783 shape, and a narrower definition would have missed it. The `bug-triage` skill gets the matching step: it runs the check for every issue it classifies as a bug, requires a `Regression:` line per bug in its summary issue, and collects everything it labelled into one section so a release manager can read them without scanning the priority sections. It applies the label only on positive evidence — an inconclusive result is recorded as unclear rather than guessed, and does not otherwise change how the issue is triaged. ## How are these changes tested? Documentation and skill instructions only; there is no code to test. The procedure was exercised against all 19 open `priority:critical` issues before being written down, including building `1.0.0` and `main` and running reproducers for the two cases that code reading could not settle (#5783, #5456). Markdown is prettier-clean. -- 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]
