On 21.1.2016 11:42, Stefan Hundhammer wrote:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Business Case: Easier to analyse logs in bug reports.
Easier for whom? Certainly not for us. And it's us who this log is for. If we need a customer log, by all means, yes, let's create one. But that would be a completely separate log that has nothing to do with our y2log.
In fact, the feature lacks a real example (reason / use case) to justify its existence, but it has actually been filed by a Yast developer.
We could for example duplicate log.info, log.error, log.warning and write that to such a customer log.
Probably a different use case, I /think/ it's about looking into journalctl and dmesg output and trying to identify a certain point in time in Yast log (or vice versa) to find out what was happening there and why.
As a user, I'd also welcome a log with commands that were executed, files that were changed (or use a Git repo for them anyway?), but that's yet another level.
Yes, yet another feature, but doable via SCR or Cheetah or Augeas if we stick to using standardized API (we usually do anyway). Please file it if you think it would help you as a user and our customers.
But our y2log is for us for debugging. If we need to comply with weird formats, we won't be able to do many things we are doing today any more, so we will no longer be able to maintain the product.
For example, look at the new format of the storage "target map" in current y2logs. Formatting this to be bug compatible with systemd would mean to get back the one-line format which is completely unusable (I spent many hours reformatting that stuff manually just to figure out what happened in bug situations).
+1 (unless there is a workaround) On the other hand, we have a simple tool/script to reformat and colorize the log for you.
Our y2log is our most important tool. It's not a playground for people who won't be responsible for debugging stuff.
So, bottom line: We might want to write an additional customer/user log, but our y2log is holy. Amen. ;-)
I see your point, go in peace :) Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org