----- 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: > > 1. 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? > > > 2. Message IDs will have the following format: VDSM##### > > 3. 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. > > > 4. 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 > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
