poll: who really uses mutter?
John Arbash Meinel
john at arbash-meinel.com
Tue Jul 4 16:41:54 BST 2006
Martin Pool wrote:
> In general application debug logs are handy things. But I'm not finding
> mutter and .bzr.log super useful at the moment, on the crucial test of
> "when something goes wrong, can you work it out just from the logs
> messages already produced". (One can probably make a theory about the
> intersection of problem space, log setup, and typical bug where they do
> work like that, but let's leave that for now.)
> Getting .bzr.log (other than the traceback) rarely seems to add much to
> bug reports. (In 0.9 the tracback will just be printed when something
> goes wrong.) When I do add mutter calls they're typically useful for
> tracking down one particular bug and not much after that, and having
> them in the log is not so useful. Many of the existing mutter() calls
> produce noise without being very useful, particularly when they're shown
> in test failures.
I use mutter a little, but mostly for debugging. And only in the short-term.
I was pleased to see readv collapsed ?? actually start reporting a
number greater than one. But that is a small thing.
> I suppose having them go to .bzr.log does have the advantage that it
> doesn't pollute stderr if you're using it for something else.
> I have a branch where I'm trying to clean up some of the trace code. I
> propose to
> - prune or comment out some of the mutter calls that aren't helping
> - not send them to .bzr.log by default?
> - perhaps add a -D option that writes to stderr - so they're more
> visible when debugging, and to make a pressure to remove useless
As long as they are always present in the test suite logs. When you
stopped reporting tracebacks in report_exception() it makes debugging
much more painful, because now the log line is just "bzr ERROR: EPERM",
with no indication of where that was occurring. (I hacked around it by
just commenting out those lines while I was debugging).
I would also recommend that we revert some of my changes to selftest,
which put repr(stderr) into the log file. The log file is declared as
utf8, which means it might not be possible to represent certain outputs.
But repr() is *really* hard to read when debugging.
I think stdout/stderr are now properly defined as bytestreams (at least
if the command goes through self.outf). Which means they should already
be encoded by the time we want to write it to the log file.
(And as long as it isn't a unicode string, I think writing it to a codec
file will be okay.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060704/a244aa01/attachment.pgp
More information about the bazaar