On 10/09/2011 05:53 PM, Ayal Baron wrote: > > ----- 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). Continuing, Ayal's theme, I will do the following to make this easier for everyone... 1. Create a git hook that checks incoming changes for existing IDs and emits a warning. Maybe, I'll even get it to suggest the next ID. 2. Enhance the Makefile with a couple of new targets: 2.1: One target to check for duplicate IDs 2.2: One target to suggest the next ID. 2.3: Target(s) to do gettext (see the makefile I sent earlier.)
Cheers, Keith >> 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 _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
