https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380

--- Comment #5 from Mark Martinec <[email protected]> 2010-10-28 12:35:41 
UTC ---
Daryl writes:
> I can't access this bug for some reason.  I get an "undef error - Can't 
> locate Class/Singleton.pm" error.
>
> Any who... do we care about having error codes corresponding to binary 
> bits (the original codes were 0 1 2 4)?  Should the new error code be 8?

Kevin writes:
> I think it is a good idea to use binary bits because then if we need, we 
> can error with 12 and that's bitwise errors of both 4 & 8, etc. should 
> we decide to in the future.
> I can't test this because I don't use multiple channels but should be 
> add a test case?

Should the new error code be 8?  Perhaps. The docs and the code in sub
channel_failed implied that codes above 4 could be just an error count
(5,6,7,...), although apparently the counting in channel_failed() was
implemented incorrectly so it would never start counting errors, so
it seems there is no compatibility issue one way or another.
The Jasons's choice of 3 made use of the only free value complying
with the docs and not breaking compatibility.

A bitwise semantics of an error code would only make sense if combinations
of bit flags can actually occur and make sense. If more than one bit
can never turn on in practice, there is no value in assigning bits to
errors.

Let's see what are the possible outcomes currently:

 A. no errors,   no updates
 B. no errors,   some updates
 C. some errors, no updates
 D. some errors, some updates
 E. lint errors, updates available but not applied
 F. some other exit code as reported by import_gpg_key or GetOpt

Before assigning values, let's see what are sensible plans of action:

 A. none
 B. sa-compile
 C. warn
 D. sa-compile, warn
 E. alert
 F. alert

or inverted:
 sa-compile  if B or D
 warn        if C or D (or E or F)
 alert       if E or F

An additional constraint is that when everything is normal
the exit code should be zero!

Here is one attempt of assigning bits:
 bit 0:  not  some updates
 bit 1:  some errors or lint errors or other errors
 bit 2:  fatal errors like lint/gpg/GetOpt failures

So:
 if bit 0 is zero, run sa-compile
 if bit 1 is one, log a warning
 if bit 2 is one, log an alert

curr proposal
---- -----
 1   001=1  A. no errors,   no updates
 0   000=0  B. no errors,   some updates
 4   011=3  C. some errors, no updates
 3   010=2  D. some errors, some updates
 2   111=7  E. lint errors, updates available but not applied
 ?  x111=7+ F. some other exit code as reported by import_gpg_key or GetOpt

In the end - I don't know what would be the most sensible choice.
Current error codes never appear in combinations. Assigning sensible
semantics to each bit may require reshuffling values, which breaks
compatibility.

Thoughts?

-- 
Configure bugmail: 
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to