Hi list,
looking at the logging code, I was surprised: turns out the 'logging level all
everything', though quite a misnomer, was an important counterpart to 'logging
level all (debug|...|fatal)'. It worked like this:
Assuming some levels are set...
logging level foo fatal
logging level bar debug
Now 'logging level all' would override all of them forcefully:
logging level all error
# Now all categories including 'foo' and 'bar' log exactly error,fatal
# messages.
logging level all debug
# Now all categories including 'foo' and 'bar' log all messages from
debug
# thru fatal.
# manipulating individual categories has no effect at all now!
logging level foo notice
logging level bar error
# no change in logging behavior!
logging level foo fatal
logging level bar debug
# the way to get rid of the forced level was:
logging level all everything
# Now we see above configured behavior of foo == fatal, bar == debug
This is *still the case*, only that we're now ignoring the 'everything'
keyword. The consequence is that we can force all categories and clamp them to
all-the-same level, but we cannot lift that clamp anymore! :/
I think we should never have accepted the removal of 'everything' as such, it
should have been replaced with a more accurate command, like
'no logging level all'. I am considering to bring this back now, ... but
But now that we haven't had 'everything' for a long time and the outrage
about
it has been limited, I am also drawn towards completely dropping that feature,
or at least renaming it. Damage is done, no need to go back to mad naming.
From the logging discussion, we concluded that we want a command to set the log
level for all categories at once, one-time; not force-clamping all to one level
until the clamp is removed, but as if we set each individual level manually.
I've cracked my head on what name other than "all" we could want this
command
to have, 'logging level (*|each|any|set-all)'? I keep coming back to
'logging level all (debug|...|fatal)' being by far the best name for this.
Backwards compatibility: what do users see when we modify 'logging level all'
to not be a forceful clamp, but instead setting individual levels once-off?
If a user had a config of "all" coming last:
logging level foo debug
logging level bar fatal
logging level all notice
then the experience is that all categories are logging at level 'notice', and
that is what the user most likely also expects to happen. Changing the 'all'
command does not change the logging behavior one bit.
If in turn the config has "all" first:
logging level all notice
logging level foo debug
logging level bar fatal
Then the experience is still that before changing the command, all categories
are logging at level 'notice'. Most likely the user expected though to see
foo='debug' and bar='fatal', because they were set after the 'all'
-- what
other reason could a user have to keep these lines in the config file, which
don't have any effect as-is? If we change the 'all' command to not be a
forceful clamp but just a one-time set, then the logging behavior changes to
what the user likely expected when writing this config. However: if these
settings were forgotten in the config file, we would suddenly change the
logging behavior and might surprise users ... but I still kinda think we would
change it to what the user expected, right? And the user would likely go: "ah,
finally it's doing what I wanted all the while!" right?
So, I want to make 'logging level all' manipulate each individual category
once-off, I want to completely deprecate the 'everything' keyword, and drop the
"global clamp" feature entirely.
Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)' and
'no logging level force-all' to switch it off. That would be exactly the old
clamping feature just with less confusing names.
The only thing that makes me write here is that I'm only 90% sure on changing
the meaning of an existing command, of 'logging level all'. If there is no
negative feedback on this here, that would bring me to 100%.
Thanks!
~N