I have some issues with the definitions of some Bugzilla keywords. Then they also have a lot of formatting inconsistencies and once we've come to a consensus I have no idea who can make changes (the definitions seem to be stored in some sort of database). Well. Here goes anyway:
* testcase | Bugs that have a testcase attached, in source form but not | necessarily integrated into the Wine test suite.
The definition does not say what a testcase is. Also, while I totally expect the source for most test cases to be available, I think the keyword should be usable even if the source code is not published. Specifying that the source is available should be the exclusive role of the 'source' keyword.
So I would use a definition like: | Bugs where a minimal program dedicated to reproducing the bug, aka | a testcase, has been attached. The testcase need not be integrated | into the Wine test suite. If the source is available (which is | strongly recommended) add the source keyword too.
* patch | Bugs in this keyword contain a patch that are waiting for approval.
What is a 'patch that is waiting for approval'? Is it a patch which is referenced in https://source.winehq.org/patches/ ? What happens if the patch is rejected? (or drops off the list) Should the patch keyword be removed? What if the patch is in wine-staging?
To me the patch keyword should make it possible to identify bugs where someone proposed a potential fix, even if it needs to be refined to be acceptable, may break other applications, etc. Essentially anything that's not a blatant hack that checks the executable filename or replaces a properly implemented function with a stub.
So I would use the following definition: | Bugs with this keyword contain a proposed fix. The fix may be | incomplete, break other applications or be otherwise unacceptable as | long as it does fix the symptoms described in the bug and is not a | pure workaround (such as altering Wine's behavior based on the | executable filename, replacing an implemented function with a stub, | etc.).
* regression | bugs relating to programs that were working at one time but stoped | working for some reason
Except for the obvious typo, capitalization and missing full stop I'm fine with this definition. I take 'programs' to mean applications that users would actually want to use with Wine, not Wine's tests.
So maybe the definition could be a bit more explicit:
| Bugs relating to applications (excluding Wine's tests) that were | working at one time but stopped working for some reason.
* Then there is the related 'Regression SHA1' property. I think it should be ok to use that property to identify the commit causing a bug, whether that bug is a regression or not.
First note that only bugs that have the regression *keyword* appear on the regressions page: https://source.winehq.org/regressions
So if a commit adds Wine tests that fail the 'regression' keyword is not applicable but I think it would still be valuable to set the "Regression SHA1" field: - The commit message may provide valuable insight into what was on the mind of the developer who wrote the tests. - Such commits can sometimes be a pain to track down when the test has seen a lot of churn. - The commit's author is likely to have insight into the bug. - Setting the 'Regression SHA1' field allows identifying the bugs for which the above information is available. - It also lets the patterns page put links to that commit and reference it as being the source of the test failures.
Maybe a better name for 'Regression SHA1' would be something like 'Bad SHA1' or 'Introduced by SHA1'. I'm not sure renaming the field is worth it but the description could be changed from
| SHA1 of the git commit that caused the regression. to | SHA1 of the git commit that causes the bug.
* hardware | Issues communicating with HW such as serial/parallel/cdrom/usb
s/HW/hardware/ + trailing full stop
* obfuscation It looks like there is an extra space in "management techniques".
* Integration | Bugs related to Wine integration into OS (menu, MIME-types, look)
s/integration into OS/integration with the OS/ And I'd even argue that the integration is with the desktop environment (GNOME, KDE, etc) rather than the operating system.
* dotnet | Bugs that appear in applications using dotNet and that are related | to this dotNet usage instead of being independent bugs.
s/dotNet/.NET/g
* The definitions for the following keywords also have formatting issues. Either the capitalization is wrong, or the trailing full stop is missing, or both: Abandoned? hardware integration localization performance source valgrind