README.sev-conf

Severity : how important is it that you fix this right now?

Confidence : how confident is rpmgrill that this is not a false alarm?

-------

I see three ways to do this:

  1) in the code that issues a gripe; or
  2) at push-to-DB time; or
  3) by associating and updating severity/confidence tables in the DB,
     dynamically.

I propose (2) so I will start by shooting down (1) and (3).

--------------

(1) in the code that issues a gripe:

i.e. the test code that issues a gripe() adds 'confidence => high/low'
and 'severity => high/low'.

Advantages:
* Could possibly be used to selectively set severity/confidence
  using program logic, eg sometimes FooCode is important and
  sometimes it's not.

Drawbacks:
* Inflexible
* Reduces code maintainability
* Requires a respin and yum install for each change.

-------------

(3) DB association table

i.e. not modifying the results table at all, but simply adding a new
lookup table such as:

    Code         | Severity | Confidence
    -------------+----------+-----------
    FooCode      | low      | high
    BarCode      | high     | high

...then, every time a result is displayed, the web UI looks up the
severity and confidence associated with each code and displays it
as appropriate.

Advantage:
* Simple to understand and implement.

Disadvantage:
* no provision for passage of time: a given result R may be low-low
  yesterday, high-high today, and low-high tomorrow.

------------------

(2) at push-to-DB time. This is what I believe is the best idea.

Like the above, but the lookup table is only referenced when new results
are shoved into the DB. The email notifier and web UI, instead of doing a
dynamic lookup, use the static severity/confidence values in each result.

Advantages:
* No inconsistencies over time.
* Flexible: as we gain experience, sev-confidence can be adjusted easily.

Disadvantages:
* Requires adding new rows (severity, confidence) to existing DB tables;
* Slightly more complex to code.