----- 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...
- 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:
- 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
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