> 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). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
