https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #17 from Michael Storz <sa-...@lrz.de> --- (In reply to Sidney Markowitz from comment #15) > (In reply to Henrik Krohns from comment #11) > > Maybe time for pre2 soon? > > I'm seeing agreement for a pre2, but I would like clarification about where > we are with bug #7987 which is listed as an open blocker for 4.0, and bug > #7992 which is open with a 4.0 milestone, both with significant work already > committed to trunk. > > How much of what is remaining on those two is what Michael Storz is > referring to in comment #13 ? > > I think that a necessary condition for a pre-release is that there not be > any open issues targeted for 4.0 other than this bookkeeping one. It doesn't > matter what combination of closing issues vs moving unfinished tasks to > future we do. about 7987: After we clarified how the return codes of eval functions should look like, I'm about to go through all plugins and change the return codes. This is necessary because it was not clear before and the plugins do not return the correct codes in many places. I now have changes for about 25 plugins. Mostly it's the wrong code in case of a miss or after an explicit got_hit/rule_ready a 1/0 is returned instead of an undef which leads to an implicit got_hit/rule_ready being triggered. These changes should be incorporated before a pre2 in my opinion. The core of the meta rule evaluation seems to work correctly. My suggestion to change the algorithm from brute force to deterministic is more of a (major) enhancement. It would allow run_generic_tests to be used for meta rules as well, to improve performance by eliminating about 1,000 subroutine calls. Meanwhile I also understood what XXX wants to achieve with the support of parallel asynchronous lookups by rule_ready. As I said before, in the general case the developer of a plugin has to implement the logic of which combination of lookups lead to hits and which to misses in the plugin itself. However, XXX is right that DNSBLs usually have exactly one particular logic: a miss is given when all lookups lead to a miss. Conversely, there is also the case in DNSEval.pm that a hit is given when all lookups lead to a hit. Here the support must be built into got_hit. In rule_ready, however, a small semantic change must be made in my opinion. I am in the process of making these two small changes as well and testing the effects. about 7992: The possibility to introduce new tags in an easy way and to use them for rules is in my opinion an essential extension of SpamAssassin. After removing the Esp.pm plugin, these tags would allow to replace the functionality of the plugin with SA rules. However, as I have said several times, there is a lot of chaos with the tags, which is just not that noticeable so far, because dynamic tags are almost not used so far. I will definitely explain this chaos in more detail. To fix the chaos, a whole series of changes are necessary. Therefore, there are three possibilities from my point of view: - Leave the new feature of Henrik in the code of SA and don't change anything about the chaos. - Take the feature out of the code, and provide for a 4.1 release along with fixing the mess. - Leave the feature in the code, and fix the chaos before the 4.0 release. -- You are receiving this mail because: You are the assignee for the bug.
