[debpool] Re: Logging and error handling

[Free Ekanayaka]

Hi Magnus,

|--==> Magnus Holmgren writes:

  MH> This is the second major question to discuss, I believe, after the "database 
  MH> rebuild" question.

  MH> I had a look at bug #293054: An email notification feature would be nice, and 
  MH> tried to figure out how to gather useful information to put in a notification 
  MH> message, especially in the case of rejection. My feeling was that useful 
  MH> information is sent to the log in the various subroutines and not gathered so 
  MH> that it can be passed back to the user. Helper routines should generally log 
  MH> only DEBUG and possibly INFO level messages.

  MH> Also, the module-global-specific $Error variables are not particularly 
  MH> beautiful.

  MH> I think DebPool could benefit from eval/die. It would allow error messages to 
  MH> be passed back more easily, and many instances of checking the return value 
  MH> of a function call, only to set $Error to the other module's $Error and 
  MH> return 0 if the function call was unsuccessful, would go away. We could even 
  MH> be advanced and use references with die; this allows us to pass multiple 
  MH> separate lines of error messages if needed; other information can also be 
  MH> passed separately.

I don't know the code of debpool in depth, but from you tell it seems
indeed a necessary move in order to get a more flexible logging.

  MH> Some other details:

  MH> It should be possible to configure a log level; log messages with a severity 
  MH> below that log level would not be logged. That means that we need to give the 
  MH> current log levels numerical values.

  MH> REJECT should be a severity (between WARNING and ERROR) instead of a facility, 
  MH> as evidenced by the fact that all REJECT messages currently have a severity 
  MH> of ERROR and the fact that any WARNING message corresponding to a 
  MH> REJECT/ERROR one has to use a different facility. The semantics I suggest are 
  MH> that ERROR means that a more or less unexpected error occurred in processing 
  MH> (server errors, e.g. couldn't run gpg or failed to move files to the pool, 
  MH> similar to the HTTP 500 class of status codes), while REJECT means that the 
  MH> upload was unacceptable due to files missing or MD5 checksums wrong (client 
  MH> errors, similar to HTTP 400 status codes). Possibly one or two more 
  MH> facilities need to be defined (actually, all of them need to be 
  MH> well-defined).

I agree with this classifications of messages.

Furthermore I think that email notification is very important, not
only in case of failure but also in case of success. I like to be
noticed about what happened to the package I've just uploaded. Of
course having a log file is fundamental as well, as if something goes
wrong I want to be able to inspect what happened.

Ciao,

Free