Date: Thu, 10 Dec 1998 15:09:03 +1030 From: Greg Lehey <grog@lemis.com> To: Warner Losh <imp@village.org>, Eivind Eklund <eivind@yes.no> Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, Kevin Van Maren <vanmaren@fast.cs.utah.edu>, committers@FreeBSD.ORG Subject: Re: Swat teams (was: problem reports) Message-ID: <19981210150903.Y12688@freebie.lemis.com> In-Reply-To: <199812100432.VAA58834@harmony.village.org>; from Warner Losh on Wed, Dec 09, 1998 at 09:32:23PM -0700 References: <19981210043511.S15330@follo.net> <19981210123002.K12688@freebie.lemis.com> <28264.913255536@zippy.cdrom.com> <19981210124903.N12688@freebie.lemis.com> <19981210043511.S15330@follo.net> <199812100432.VAA58834@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii On Wednesday, 9 December 1998 at 21:32:23 -0700, Warner Losh wrote: > In message <19981210043511.S15330@follo.net> Eivind Eklund writes: > : So - count me among the replies :-) > > I'm in. I'll volunteer to do something to help. I can spend 4 hours > a week on this task. If there is something that can be done without a > great deal of thought, then I'll do it. Well, I don't have my 5 people together yet, but I was snooping around on my system and found the attached piece of antiquity. It obviously doesn't apply to FreeBSD, but you may find some of the ideas of interest. And yes, it is genuine. Nothing has been changed. Anybody care to hazard a guess what text formatter was intended? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=SUPNOTE \poff 7 \sect "Page " 1 \foot "Support Note S85???: Responding to TPRs *** PRELIMINARY ***" \outlen 70 \center 4 SUPPORT NOTE S85??? Responding to TPRs Greg Lehey 2 September 1985 \text on This support note describes methods and conventions involved in answering TPRs. It is intended for use by Tandem Support and Development personnel only; other employees should not normally respond to TPRs. This is not a complete document. It is intended as a supplement to Support Note 82007A. \text off \ov 1. TPR routing ______________ \text on TPRs may be entered in the field, at support nodes or at Development nodes. Field TPRs are then routed through one of the "field" SSGs (Sunnyvale, Reston or European), where they may be answered or forwarded to Cupertino SSG (\SSG). Here they may be answered or forwarded to a Development node. TPRs which arrive at Cupertino SSG or a Development node without following this route should be returned unanswered. TPRs submitted from Support or Development should be send to Cupertino SSG, where they will be handled as before. \text off \ov 2. TPR verification ___________________ \text on Once a TPR has been assigned to you, you should verify that is is intelligible and complete. Guidelines for TPR entry are to be found in Support Note 82007A; you should verify that the TPR conforms to these standards. In particular, \text off - The problem should be concisely described - The details specified on the "front page" of the TPR should be correct: It should - refer to the correct product number - specify the correct date of the product - specify the correct location of the accompanying information. The names should agree with the subvolume naming convention. - specify the correct customer address - contain the detail text in the TPR, not on some node at the other end of the world - supply all the files needed to solve the problem on a single, correctly named and correctly secured subvolume. \text on If this is not the case, the TPR should be corrected and an appropriate note placed in the response text, along with reasons for the change. Repeated offenders should also have the TPR graded 1 (see below). This function should already have been performed by the SSG. If you are in Development and receive a TPR which has not been fixed, you should also contact the SSG person who reviewed it and point out his error. \text off \ov 3. Reviewing/Responding _______________________ \text on It is beyond the scope of this document to describe how problems are analysed and fixed. The important thing is to ensure that either \text off 1) you can solve the problem yourself, or 2) there is somebody further up the ladder who can, or 3) there is nobody who can solve the problem. \text on 1) If you can solve the problem yourself, then do so. THEN decide: Is there somebody further up the ladder who should be informed about this? This depends on where you are: a) Field SSG. If this is anything but a trivial problem, it should be forwarded to Cupertino SSG, at least for documentation purposes. If the solution involves code changes, it MUST be forwarded to Development. If not, it should be forwarded to Development as an FYI TPR. In either case, tick the DEVELOPMENT box on the Response Screen. If it is a trivial problem, return to the field. Tick the FIELD box on the response screen. Do not enter a system name. b) Cupertino SSG. If the solution involves code changes, it MUST be forwarded to Development. Otherwise return to the field as described in a) above. c) Development. Probably there is nobody. If it involves code changes, ensure that they get in the next practicable release. Do not wait until the release before returning the TPR. Enter a PMN (see the appropriate documentation) and return the TPR to the field. 2) If you can't solve the problem yourself, then a) Field SSG. If there is nobody in your group who can handle the problem, review the TPR as far as you can get. If there is any hope that it can be solved, forward it to Cupertino SSG with the request that it be assigned at \SSG. Tick the SUPPORT box on the response screen. If the TPR is a hopeless case (especially if there is not enough information to make a solution possible), return it to the field. Tell the submitter what to do if the problem occurs again (what to look for, what information to submit). b) Cupertino SSG. If there is nobody in your group who can handle the problem, review the TPR as far as you can get. If there is any hope that it can be solved, forward it to Development. If the TPR is a hopeless case (especially if there is not enough information to make a solution possible), return it to the field. Tell the submitter what to do if the problem occurs again (what to look for, what information to submit). c) Development. You're on your own. Decide with the help of your manager. Do not "sit on" the TPR - if nothing better occurs to you, return it to the field with an explanation of why you can't do anything with it. If possible, describe what action to take if the problem happens again. 3) If the problem turns out not to be related to the product against which it was entered, describe your reasoning why the problem is not related to the product. Then change the product number to what you think it should be. If you are responsible for this product as well, then carry on your analysis. Otherwise reassign to your PRS coordinator for further action. In Development, this may involve returning the TPR to Cupertino SSG for reassignment. Do NOT just return the TPR to the field! \text off \ov 4. Response texts _________________ \text on To make TPR responses, several conventions make life easier for all concerned. These are not required, but recommended: \text off - Enter all texts in dual case (i.e. normal English writing) - Remember that date formats vary. Use unambiguous forms (e.g. 2 September 1985 or September 2 1985, depending on your convictions, but not 2/9/85 or 09.02.85 or whatever). - Use the following standard texts: Reviewed by <me>, 2 September 1985 - use this if you look at a TPR, but are not in a position to formulate a definite reply. May occur several times in a response. Reply by <me>, 2 September 1985 - use this if you do have a definite answer and propose to return the TPR to the field immediately. Sent to \SSG, please assign at \SSG - (field SSGs only): Use this if you are not able to solve the problem yourself and need it to be looked at at Cupertino SSG. Sent to \SSG, please forward to Development - (all users in Support and Development): Use this if you have a solution which should be brought to the attention of Development, or in the case of an RFE. Sent to \SSG, please forward to Development FYI - (all users in Support and Development): Use this if you have information which should be brought to the attention of Development. \text on In all cases, the message "Sent to \SSG" (or "Sent to Cupertino SSG") should be the last line in the response text. This makes life easier for the PRS administrator at Cupertino SSG. \text off \ov 5. Response dates and severity ______________________________ \text on TPRs may be graded with severities between 0 and 3, 3 being the highest. The exact meanings of these are described in Support Note 82007A. In general, TPRs with a severity of 2 or 3 are considered extremely serious problems; the allocation of these severities should be justified in the text. If they are not, you should establish contact with the submitter and establish why he has allocated this severity. It is a good idea to include mail messages in the TPR response. Similar considerations apply to response dates, which default to one month after submission. \text off \ov 6. Grading TPRs _______________ \text on PRS offers the ability to specify what you think of the quality of the problem report by "grading" the TPR. There are 3 grades: \text off 1: This is a very poor TPR, worse than 90% of all TPRs 2: This is a normal TPR 3: This is a very good TPR, better than 90% of all TPRs. \text on The grading relates only to the quality of the report provided by the submitter, never to the problem or its handling, either by customer or Tandem personnel. It also does not relate to responses by people other than the submitter. \ov When to grade? ______________ In case of doubt, don't. If, however, you get a TPR which, by virtue of the way it was entered, makes life easy or hard for you, then grade it as grade 3 or grade 1 respectively. If you find it already graded by somebody who looked at it before, think very carefully before overwriting it. In either case, the fact and the reasoning should be documented in the TPR response text. Typical cases might be: Grade 3: The submitter has entered a TPR which essentially contains the analysis performed to such a stage that there is little, if anything, which you need to do. If a workable solution is provided, you should certainly grade it 3. Grade 1: The submitter has neglected to supply information known to him, has placed his files on the wrong subvolume or secured them such that you cannot access them, or has neglected to supply available information such as dumps or CONFLIST. Before grading a TPR 1, bear in mind that Tandem has a large number of employees who are new to the business and may not have been told how to enter a TPR. In case of doubt, explain to the submitter what he has done wrong, and do not grade the TPR. If he persists, however, the TPR should be graded accordingly. --f0KYrhQ4vYSV2aJu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981210150903.Y12688>