duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loglevels and Output ... WAS: Re: [Duplicity-talk] erroneous increm


From: Michael Terry
Subject: Re: Loglevels and Output ... WAS: Re: [Duplicity-talk] erroneous incrementals?
Date: Fri, 27 Mar 2009 12:48:50 -0400

On Wed, Mar 25, 2009 at 8:39 AM, Edgar Soldin <address@hidden> wrote:
> the log level hint might help people familiar with and searching for
> this term. Of course this makes only sense if the --log-* commands
> interpret it. Else we should think to differentiate the terms for both
> outputs (output verbosity vs. log level). Let's see what Michael has to say.

Sorry, I meant to reply to this, but forgot.

-log-* commands do respect verbosity setting.

The list of settings that Ken gave is accurate, but let me explain them a bit:
   logging.addLevelName(DupToLoggerLevel(0), "ERROR")
   logging.addLevelName(DupToLoggerLevel(1), "WARNING")
   logging.addLevelName(DupToLoggerLevel(2), "WARNING")
   logging.addLevelName(DupToLoggerLevel(3), "NOTICE")
   logging.addLevelName(DupToLoggerLevel(4), "NOTICE")
   logging.addLevelName(DupToLoggerLevel(5), "INFO")
   logging.addLevelName(DupToLoggerLevel(6), "INFO")
   logging.addLevelName(DupToLoggerLevel(7), "INFO")
   logging.addLevelName(DupToLoggerLevel(8), "INFO")
   logging.addLevelName(DupToLoggerLevel(9), "DEBUG")

In the code, there are standard mappings from log.Error to specific
levels: 'Error' == 0, 'Warning' == 1, 'Notice' == 3, 'Info' == 5, and
'Debug' == 9.  There are duplicate levels per name because some levels
just didn't have names and I needed something.  Please don't change
any of these level names without good cause.  This mapping is only for
log-consuming programs.

The internal code can use a different mapping if needed (that is, if
we wanted to make log.Notice default to level 4, that wouldn't
necessitate a change in these logging names).  But external programs
rely on the existing names to some degree, and changing them has to be
done carefully.

In addition, changing a message's level so that it changes logging
names has to be done carefully too (like, moving something from DEBUG
to INFO).  If someone (really, just me at this point I think -- have
you used the logging yet Ed?) depended on a particular DEBUG message,
but you wanted to move it to INFO, ideally we'd still log both
versions but only print the INFO one to the console for normal users.
Of course, that shouldn't happen often.

-mt




reply via email to

[Prev in Thread] Current Thread [Next in Thread]