| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
NOTE: This account is for DIGITAL INTERNAL USE ONLY
It is now very easy to enter a QAR in the VMS QAR System on node TRIFID.
Please use this account to enter QARs for the following products:
VMS
Volume Shadowing
DECnet-VAX
RMS Journaling
VAXcluster Software
DECwindows
VWS (VAX Workstation Software)
To enter a QAR, simply SET HOST to node TRIFID and login with the username
QAR_INTERNAL and password QAR. A list of available QAR databases will then be
displayed. At the prompt "Which QAR database? " choose the appropriate one
based on the nature of the problem you are reporting, for example:
- Enter VMS problems on released (SDC) software in the "V5" database.
- Enter VMS problems on field test software in the appropriate
field test database, (e.g. V52-IFT).
At the "QAR>" prompt, type the command "ENTER" to enter a new QAR.
You will then be prompted for the following (once per login):
Name
Cost center number and name
Enet mail address
Phone number and mail stop
CPU type
Memory size
System device
For each QAR entered, you will be prompted for the following:
VMS version
Attachments (ie, LISTING, TAPE, etc.)
Publish (QAR can be read by "others")
Reproducible ("problem" can be reproduced at will)
You will then be placed into the EDT editor where you can enter text to
describe your problem. Please include examples if possible. If you have crash
dumps, make them readable and tell us where they can be found. Please report
only one problem per QAR.
NOTE: Please do not use this account to report security problems or problems
which allow unpriviliged users to crash the system. Use an individual account
(QE_ or QD_) if one is available, contact TRIFID::QAR$MANAGER or a cognizant
VMS Developer if an individual account is not available.
You will automatically receive mail notification when your QAR is answered or
closed.
You can also use this account to review QAR's.
NOTE, this account should be used by all employees who are NOT formally
participating in any VMS field tests. If you are doing lots of testing and
expect to be entering numerous QARs on occasion, then send mail to
TRIFID::QAR$MANAGER and request your own QAR account. (To avoid just getting
another copy of this note mention that you have tried the QAR_INTERNAL account
and why it does not meet your needs.)
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2.1 | Why we would like the QAR system used whenever possible | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Fri Mar 09 1990 14:58 | 73 |
Peter Vatne inspired me to do something I have been planning to do for a long
time...Several years ago when I was a UIS Devo, I wrote an explanation of why
we want bugs put in the QAR system instead of the notes files. It got spread
around to a number of conferences, and I kept meaning to spread it here, but
never got around to it. Finally, I searched through VMSNOTES and found it.
I should add that we understand that there are a lot of issues around using
the QAR system, especially for those of you connected via slow links. You
don't have to flame.
Here is the note...
----------------------------------------------------------------------------
Let me expound a bit on why we always say that this notes file
(and VMSNOTES and MICROVAX for that matter) are not good places
to report bugs and expect them to get fixed.
The main reasons are
1. Quantity
2. Organization
3. Measurement/Visibility
1. Quantity
We get hundreds of reports of bugs and non-bugs. We have a
limited number of people to work on them. We have to choose some
way to decide which bugs get our attention. (I'm sorry...I would
love to fix EVERY SINGLE BUG and answer EVERY SINGLE QUESTION, but
choices must be made.) The QAR system exists for the purpose of
reporting bugs. Therefore we choose it (and SPRs) as the highest
priority bugs to fix, or at least respond to.
2. Organization
The QAR system is organized specifically to help us track bugs:
what they are, when they were reported, whether they have been fixed,
and who is responsible. Notes are not so organized. If you leave
a bug in the notes file, it requires a lot of manual tracking to make
sure that it does not get forgotten and to coordinate who is keeping
track of it, etc.
3. Visibility
QARs are visible to lots of people: customers, management, other
internal engineers, etc. There is pressure to get QARs answered.
There is less pressure to answer notes files. If someone asks me
why I have not answered my QARs and I say that I was responding
to notes, guess what the response will be?
So what do I think SHOULD be done with bugs and the notes file?
Here is one appropriate procedure, as I see it: You find something
you think is a bug. Put it in the notes file to alert other people
to the problem. Thrash it around. Often you will find it is not
a bug, it is your error, or a "feature" that can be explained in
notes. If it is a bug, perhaps someone can suggest a workaround
and/or other aspects which will make it clearer. When it becomes
clear that it is a bug, someone (probably the original poster) must
take the responsibility to condense the discussion down to a cogent
explanation of the problem and put it into the QAR system. There
are probably other appropriate procedures, but they have one thing
in common: If there is a real bug, that bug gets into the QAR system
somehow.
If you don't have an account on the QAR system, send mail to
TRIFID::QAR$MANAGER.
Thanks to everyone for your understanding. With everyone's help,
we can keep weeding the bugs out of VWS.
Burns
| |||||