On 2021-01-15 16:29, Lukas Ocilka wrote:
[errors/warnings in the y2log going unnoticed for a long time]
IMHO the major problem with this is that we are neglecting the y2log.
Lots of cruft get logged all the time in certain parts of the code while
other parts of the code don't do ANY logging at all.
Try turning Y2DEBUG on and watch in amazement the wall of text that
keeps scrolling by. That's where things go downhill. In that wasteland
of useless messages it's impossible to find anything, so we stopped
caring.
We need better discipline with logging. When you are done developing
some piece of code, turn excessive logging off. I normally simply
comment out the log lines so they are still available when I need to get
back to that part to continue developing; or for serious debugging.
Some months ago, for example, I threw out a ton of y2debug() from
libyui-ncurses; that level of debugging was close to what gdb will give
you if you let it. We don't need to log every constructor and
destructor. We don't need to dump all the internal status of an object
in every function.
When y2debug no longer keeps flooding people with useless stuff, they
will be more inclined to watch the y2log, so errors and warnings are
spotted more easily.
Also, if a warning or error occurs on a regular basis, it's probably not
an error or a warning, but a normal message. During normal operation,
there should be NO error and very few warnings.
We need to get over throwing and catching exceptions on a regular basis;
during normal operation, there should be no exceptions. In certain parts
of our code (libstorage?) we may need more check functions; or maybe one
or more flags meaning something like "I know this can go wrong, so don't
complain (too loudly)". Probing comes to mind as an example.
Many years ago, we used to check the y2log for warnings and errors
before each release, and if there were any, we decided to either
downgrade the message to y2milestone or to fix the underlying problem.
IMHO this is still the way to go.
So, IMHO rather than inventing yet another level of problem reporting,
we should clean up what we already have. Since we have been neglecting
that for so many years, it will take a while; but still this is clearly
necessary. Please let's not work around that problem with yet another
layer of indirection. Remember RFC 1925? ;-)
Kind regards
--
Stefan Hundhammer