----- 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
> >>>> 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
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to