Nathan Wrote:
> Can we relax this to say "no substantive changes"?
> If we fix a typo or even wording:
> "[1234] lustre has dropped the ball and erased all your data" to
> "[1234] an irrecoverable error has occurred and erased all filesystem
data"
> doesn't seem to me that it should require a new message number. Parsing
> tools should
> just check the number and not worry about the exact contents of the
message.
> I think that's the whole point of having a [number] in the first place.
Jody Wrote:
Perhaps, but what about a typo fix, for example:
-Lustre [ID 1234]: Server handling error on servr [EMAIL PROTECTED]:
+Lustre [ID 1234]: Server handling error on server [EMAIL PROTECTED]:
transaction 11602746/0, opcode 42 returned -2
Looks innocent enough, except the web-based parser may be depending on
the word "servr" to pick out the "[EMAIL PROTECTED]" NID.
I think to avoid problems like this, we need to ban reuse across the
board. I don't think Lustre messages are changed often enough that we
need to worry about running out of numbers.
Jody, that looks like a pretty brain-dead parser to me. I agree with points
taken by various people, in particular:
1. If _new fields_ are added to a message, then I think that it deserves a
new number (for the reasons mentioned earlier)
2. But, if text is modified in some minor way to improve readability or
correct spelling errors, it should use the same number. Too many numbers
that mean the same thing (in different releases) is problematic.
3. The programmer should recognize certain unusual cases (like the one
above where the "field name" is mis-spelled), and then create a new number
in this case.
4. All fields should be surrounded by spaces (never extra colons,
semi-colons, commas, or periods) -- this should make parsing easier. That
saves the parser from having to remove them.
5. (I have not seen this topic addressed) If a message can occur in the
code in multiple places, then there must be some distinguishing feature so
that the reader can know which line of code generated the message (if
applicable). Personally, I like __FILE__:__LINE__. But, there can be other
ways to distinguish which instance of a particular message is the culprit.
Just my 2 cents.
-Roger
_________________________________________________________________
Dave vs. Carl: The Insignificant Championship Series. Who will win?
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://davevscarl.spaces.live.com/?icid=T001MSN38C07001
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
