[chirp_devel] [PATCH 1/7] Add chirp.logger module (#2347)

[Dan Smith]

> That said, I could just fake it, since it's apples to oranges anyway.
> As long as it's unique for each patch, it should serve for the
> purpose that you describe, yah?

Yes.

> That would be fairly easy to add; in the git-patch-to-hg-patch
> script, hash the original email message (which includes a time/date
> string) and then emit it as part of the body.

The hash identifies what you sent, not when you sent it. The two are the
same to me, but not to you, so the timestamp is fine with me, but I
think the hash is the right thing to do. Well, actually, I think the
right thing to do is use our tool, but, you know.

>> What is the point of writing the raw string into the file before we
>> open it? That said, the above should be this for consistency:
> 
> Well, it works.  The string does make it into the log file.

Sure, but that wasn't the question, the question was: "why?"

> It's not a log message because that would end up on the console as
> well, and we should not unilaterally spam that line at every launch
> (as that could preclude chirpc from being usable in command
> pipelines).

Logging at DEBUG level seems appropriate, regardless of where it ends
up. So far, you're still relying on the stdout intervention for
generating debug.log on Win32, so logging it, having it go to the
console, and thus ending up there is appropriate at the moment. When you
add a FileHandler for debug.log, you can set that to DEBUG, let the
console handler default to INFO, and then you won't see it on the console.

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20150226/f6ca6765/attachment-0001.bin