Hi Andreas, On Thu, Dec 28, 2006 at 04:43:14PM -0700, Andreas Dilger wrote:
> Other companies uses messages of the form MMMM-NNNN (component-msgnum) > so that messages can be allocated separately between different pieces > of software or components (e.g. MGS, LMV, or other parts of the code > that are being worked on independently). That could be useful, but it makes the message longer. Sun managed to come up with a unified set of message numbers (with 6 digits) for all of Solaris so we should be able to do this as well. > One issue with this is if a message is unclear or otherwise lacking > information and it needs to be fixed then it presumably needs to have > a new message ID. That in turn means that the message database will > have duplicate information, or there needs to be a facility to link > different messages together like "XXXX: (previously YYYY, ZZZZ)"... I don't understand why this duplication is a problem or why we would need to "link" back to previous messages. > There are already 2224 CWARN and CERROR messages in the current code > base, so I'm not sure a use-once 4-digit number is large enough. We can extend to 5 or more digits later if needed. That's explicitly part of the proposal and required of any parsing tool. > Another alternative is to allow the format to "grow" by adding on > elements to the end and allowing the "non-format" parts of the > message to change (improved wording, etc) so long as there are no > changes in the order of existing format elements. Yes. See my comments to Nathan about parsing messages, but maybe I'm being too rigid here and wording changes are OK. I do not want to allow "growing" the format under any circumstances though. The reason is that we need to distribute the web-based parser so that it can be used by secure sites, and I want the parser to be able to say "no, I don't know how to deal with this message; you need to upgrade me" rather than provide an incomplete (or incorrect) interpretation. Allocating a new message ID (which would be recognized by an outdated parser as "too new") is the most reliable way to do this. > As for "committed to any branch of CVS", that imposes a burden > on in-development code which might have numerous changes before > the code is first released... True. My goal here was partially paranoia and partially to make sure we can always interpret messages in Buffalo, which sometimes tests non-production branches. Perhaps this requirement could be relaxed to "committed to any production branch" - but then we need to define "production branch." Can we guarantee that customers (including partners) will never pull or be given code from branches other than b1_4, b1_5, and the release branches? Cheers, Jody > > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. -- _______________________________________________ Lustre-devel mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-devel
