RFC: Bugzilla keyword definitions
fgouget at free.fr
Tue Jul 6 05:37:10 CDT 2021
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:
| 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.
| 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,
| 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.
| SHA1 of the git commit that causes the bug.
| Issues communicating with HW such as serial/parallel/cdrom/usb
s/HW/hardware/ + trailing full stop
It looks like there is an extra space in "management techniques".
| 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.
| Bugs that appear in applications using dotNet and that are related
| to this dotNet usage instead of being independent bugs.
* The definitions for the following keywords also have formatting
issues. Either the capitalization is wrong, or the trailing full stop
is missing, or both:
Francois Gouget <fgouget at free.fr> http://fgouget.free.fr/
Theory is where you know everything but nothing works.
Practice is where everything works but nobody knows why.
Sometimes they go hand in hand: nothing works and nobody knows why.
More information about the wine-devel