Fedora Notifications - howto?

Michael Schwendt mschwendt at gmail.com
Sat Aug 22 10:56:25 UTC 2015


> At the top of the filter I can read:
> 
>   | (all these rules must be satisfied for the notification to be sent)
> 
> This is misleading. Actually, only all the green "include" rules must
> match (= be satisfied) for a notification to survive the filter. Any
> red "ignore" rule that causes a match, immediately deletes the
> notification from further processing => nothing sent to you.

Each filter is a logical conjunction, with the rules being operands
that contribute as a logical AND:

  R1 /\ R2 /\ R3 /\ ...
  
Each "ignore" rule contributes as a NOT:

  R1 /\ !R2 /\ !R3 /\ ...

Simply negating an operand (switching a rule from "ignore" to "include")
has too much of an impact on the final outcome, since it changes the
entire formula.

Looking at the filtering with that perspective, it's clear to me,
instead of wondering about the names of the two default filters and
wondering whether those names might be relevant. ;)

  "Events on packages that I own" : this filter eliminates several
  less interesting notifications related to packages where you are
  on the "commit" or "watchcommit" ACL; for example, it deletes also
  notifications you've triggered yourself when you touched the packages

As quickstart, better than the default filter name would have been a
brief textual description of what each default filter is supposed to
achieve. 

All filters are applied to all "events" (i.e. "notifications").
That makes each filter an OR operand of another logical conjunction.
Multiple filters that match a notification would still cause it to
be delivered once only. Something ignored by one filter may still
be included by another filter.

It's a helpful system, provided you want to filter at "the source" and
not after receiving the notifications (with e.g. procmail).


More information about the devel mailing list