----- Original Message ----- > On 10/10/2011 08:44 AM, Ayal Baron wrote: > > > > ----- 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. > Understood. Can I get an ETA though?
Need to solicit responses on the list. Dan, Saggi, Edu, Federico, please reply with your thoughts on this. We already know that in the next 2 versions the code is going to change *a lot*. So it's not clear what the value of doing this at the present moment is (adds pains for something that will change 10 times in the next year or so). > >> > >> 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 > >>>> [email protected] > >>>> https://fedorahosted.org/mailman/listinfo/vdsm-devel > >>>> > >>> _______________________________________________ > >>> vdsm-devel mailing list > >>> [email protected] > >>> https://fedorahosted.org/mailman/listinfo/vdsm-devel > >> _______________________________________________ > >> vdsm-devel mailing list > >> [email protected] > >> https://fedorahosted.org/mailman/listinfo/vdsm-devel > >> > > _______________________________________________ > > vdsm-devel mailing list > > [email protected] > > https://fedorahosted.org/mailman/listinfo/vdsm-devel > > _______________________________________________ > vdsm-devel mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/vdsm-devel
