Change the way of logging gomuks? about gomuks HOT 8 CLOSED

Is ~/.config/gomuks-logs/debug.log or same dir in ~/.cache a sensible enough place for this? Does it also make sense to deisable logging by default and start it only when user asks for it?

from gomuks.

/cc @tulir @alexmyczko

from gomuks.

Here's the spec for it: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
~/.config/state

from gomuks.

I wouldn't use .config for log files. I would prefer .local/share. IMO .config should only contain config files, for instance ones that should be backed up. .local/share seems more appropriate for random data. It is corresponding to the $XDG_DATA_HOME in the page you linked @nileshpatra.

Also after reading this page it seems that you made a mistake, ~/.config/state should be ~/.local/state.

from gomuks.

from gomuks.

I found some time and have opened #430 to address these issues. I'd be great if I can get a review.

from gomuks.

Thanks for merging the PR and closing the bug. I had one ask -- would it be possible to cut a patch release at this point and update the debug docs to reflect the change in debug log thingy starting from the new version?

This is so because I could update the package to the new patch release in debian and it'd work. Otherwise, I'd have to backport this patch (not an issue) but users maybe confused to see a different behaviour than upstream in debian package for the same (0.3.0) version.

Please let me know what you think?

from gomuks.

Thanks for merging the PR and closing the bug. I had one ask -- would it be possible to cut a patch release at this point and update the debug docs to reflect the change in debug log thingy starting from the new version?

This is so because I could update the package to the new patch release in debian and it'd work. Otherwise, I'd have to backport this patch (not an issue) but users maybe confused to see a different behaviour than upstream in debian package for the same (0.3.0) version.

/cc: @tulir given that there have not been many commits (and breaking changes) since last release. Is this something you'd consider doing? I'd appreciate any response.

from gomuks.