RFC: Bugzilla keyword definitions

[Francois Gouget]

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


-- 
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.