Hi Neels,
On Wed, Jul 25, 2018 at 04:22:09PM +0200, Neels Hofmeyr wrote:
A) The hardcoded logging landscape on program startup without config. (Maybe this isn't all that important, including it nevertheless.)
- a command to reset all to hardcoded defaults?
ACK
B) A "normal" logging behavior configured by the user. We need:
- a command to set all categories at once
to set all to one level, or to set all to one set of (configurable) defaults, like a template?
- a command to tweak individual categories
ACK.
C) Temporarily reducing the logging on all categories: silence the log. Even though a category is "normally" set to INFO, after this command it can be forced down to only log e.g. NOTICE. But if a category is already on ERROR, leave it down there and do not lift it up to NOTICE.
- a command to temporarily reduce all categories.
- a command to temporarily reduce individual categories.
Not sure for what one would use that. You could switch off logging completely and re-enable it later?
D) Temporarily increasing the logging on all categories: show everything. Even though a category is "normally" set to ERROR, after this command it can be forced up to e.g. INFO. But if a category is already up at DEBUG, don't reduce it to NOTICE.
- a command to temporarily increase all categories.
- a command to temporarily increase individual categories.
- we need to decide whether temporarily increasing is stronger/weaker than temporarily reducing. Depending on the implementation, it could also be "last one wins" (which IMHO would be best).
Sounds incredibly complicated to me.
T) Maybe we also want to unconditionally set temporary levels, whether they increase or reduce.
?!?
E) Remove temporary logging to go back to the "normal" logging landscape.
- a command to put everything back to "normal",
- a command to put individual categories back to "normal",
- a separate command to only remove temporary reduction, i.e lift the temporary changes only if they cause less logging than normal,
- a separate command to only remove temporary verbosity, i.e. only lift the temporary changes if they cause more logging than normal.
WTF? Why all that complexity?
Honestly, I'm stopping at that point. Just finishing to read that one e-mail, let alone the entire thread will cost me hours.
To me, it boils down to a hypthetical luxury problem, unless there's somebody who is actually funding/contributing the amount of time required to designing, debating, implementing, reviewing and merging and overhaul of the logging sub-system.