----- Original Message -----
On Fri, Oct 07, 2011 at 10:28:17AM -0400, Keith Robertson wrote:
OK, unless anyone has anything else to add I'm going to assume that the project maintainers are OK with message IDs and I'll start the process.
I must say that from my perspective, this adds a lot of work for a very small gain. I suspect that your perspective, of having to correlate different logs, is slightly different.
Even though you've volunteered to do the first giant leap for man kind, it is going to be quite tedious for me to maintain it for each and every future log-using patch. I shiver of the thought of one patch adding VDSM1234 in parallel to another one - I hate to be the synchronization mechanism of this. Surely, we could use git hooks to help, but no matter how you look at it, it adds pain to development process. Even the simple NACK for "dude, you've forgot _(bla)" is counter-effective.
This can be easily and *entirely* automated. In fact it could be autoresolved so you wouldn't even have to nack it (found a conflict with msgId? automatically change that line in the patch, should be quite simple even).
However, if consensus is reached that this is truly helpful for users trying to figure out what went wrong, I am willing to to dive in.
To summarize:
- I'm going to do some minor surgery to the logger so that the log
format is pinned an not user modifiable. This is necessaory to ensure that message IDs can be substituted into the string.
Do you mean a log adapter? Something else?
- Message IDs will have the following format: VDSM#####
- Message IDs will just be a simple up-counter across all of VDSM.
and a `make check` test to find collisions, and a `make nextID` rule to find the next free message ID.
- Existing strings will be converted to translatable strings. The
string itself won't be changed it will just be wrapped by _(...) so that gettext will work. 5. Message IDs may be documented, somewhere not sure where yet, with a brief explanation (if an explanation is appropriate). This part might take some and; hopefully, the explanations will evolve. I expect many of the IDs to not have explanations right away though and I definitely don't want to put any bad explanations up or ones that haven't been vetted.
Since the explanations are going to sit remotely from the explained code bit, they would be quite susceptible to comment rot.
As you can see, I'm not yet thrilled about this suggested project. Let's see how a proof-of-concept of this looks like.
Regards, Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel