----- Original Message ----- > 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.)
Please wait with actually working on this, I think there is some contention about the value/cost ratio of this change. I would like to see comments from a few extra people and I would hate for you to do all this work just for it to get nack'd. > > > 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 > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
