https://bugs.winehq.org/show_bug.cgi?id=54656
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- (In reply to François Gouget from comment #7)
By that definition >99% of the commits are not regressions since they don't introduce new Wine dependencies. And I'd argue that now that updating the GitLab CI falls on the shoulders of Wine developers, a commit that fails to update the GitLab CI to test the new code is a regression.
The definition is not limited to dependencies, but yes, >99% of the commits are not regressions, that's the way it should be. That's what makes things like the regression hall of shame useful. If we apply the keyword to any change of behavior that someone doesn't like, it becomes useless.
A regression has to be something that can be pointed to a specific piece of code that worked, and got broken by a change, and where the fix will most likely involve refining the change.
For instance, a bug in a newly-added dll would not be considered a regression. From the user's point of view it may be a new problem, since obviously the bug didn't happen when the dll didn't exist, but from the developer's point of view, there's no previous version of the code that worked, so it hasn't regressed. The goal of Bugzilla is to provide meaningful information to developers, and there's no useful information to gather from the fact that a bug didn't happen when the code didn't exist.
So not running a test that didn't exist previously, to test code that didn't exist previously either, should not be considered a regression in the sense of the Bugzilla regression keyword.