🚀 go-pugleaf

In article <DOWDING.91Mar15093959@sunset.ai.sri.com>, dowding@ai.sri.com (John Dowding) writes:
> Because no vendors will respond favorable[sic] to the request to declare
> publicly to a potential (or actual) customer all the known bugs and
> shortcomings of their product.

I wonder about that.  When I was a student at Auckland University, we
had a Burroughs B6700.  A couple of times a year Burroughs provided a
FTR/TAR collection (FTR = Field Trouble Report, TAR = Trouble Analysis
Report).  These were fairly thick lists of all known problems, both the
ones that had been fixed and the ones that had not been fixed.  From
time to time I would try some of the "not yet fixed" ones to see if we
had those problems, and we usually did.  I don't recall them being
subject to any form of non-disclosure, and there was nothing to stop
any potential Burroughs customer wandering in and looking at them.
DEC used to do the same sort of thing for RT-11 and VMS, and I presume
they still do.  One AT&T documentation set for UNIX V.3 that I saw had
a list of known remaining problems.

I have no idea what Quintus's current policy is.  I don't recall them
publishing a list of bugs when I used to work for them, but if someone
asked "is this your bug or mine" they got an answer by return E-mail,
and nobody ever said "don't tell".

Vendors are in it for the money.  Some vendors are big enough to ignore
individual customers, but most Prolog companies that I know about are not.
If you go to Quintus, ALS, Integrated Solutions, LPA, &c, and say "I am
interested in buying X number of copies of your product, but only if
you give me a list of problems currently known not to be fixed, and
yes, I am willing to sign a non-disclosure agreement", then they are
going to think very hard about doing it, because your purchase is big
enough to be noticed.

> Over the years I have submitted a number of bug reports to a variety
> of vendors.  In each case, I have never known if they knew about this
> bug already, or if mine was the first report.  Who knows how many
> times I have spent hours tracking down bugs in products that the
> vendor already knew was there?  (That is a rhetorical question, Richard)

How many times did you *ask* whether they already knew about the mistake?
From my own experience, SUN *did* tell you whether your problem was a
known one (after you submitted it), provided the person submitting the
report was the official contact person for the site.

By the way, my understanding of a "support contract" is that information
like this "feature such and such has mistake so and so, we intend to fix
it soon/in the next release/eventually, in the mean time here is how to
work around it" is one of the things that such a contract is FOR.  Again,
I would point out that most Prolog companies are small and hungry.  If
you demand this kind of thing as part of the "support" you are paying
for, they are hungry enough for the support money to listen and maybe do
it.  (It takes a fair bit of staff and time to track bug reports and
distribute this kind of information, so I think it is perfectly fair of
vendors to ask for money to do it.)

> In any case, it is certainly not the vendors[sci]place to tell us what
> should and should not be discussed on the net.

I'm not a vendor.  And the point of my posting was not to say
"thou shalt not" but to say "DO YOURSELF A FAVOUR, go FIRST to the
people who really DO have the answers, as opposed to the people who
only think they have the answers."

The law varies from country to country.  My understanding is that in
NZ and OZ vendors can get away with pretty well anything in their
advertising, but that if you write and ask "does your product do X"
and they state in writing _in reply to a specific request_ that their
product does X, then they are legally required to be telling the
truth.  Do you begin to see how something like this could be used to
shape the situation so that it is in the vendor's interest to tell
the truth about known problems?

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.