>Alan,
>Any dynamic information (and I classify BUG/PRB information as dynamic) shipped with the product would unfortunately be obsolete by the time it got to you. MS provides http://support.microsoft.com for this reason. Doing an advanced search and using PRB: "Visual FoxPro for Windows ?.0" will give you a list of all known issues (up to maximum of 150) that have cleared the review process. You can specify any additional keywords to narrow that to your particular issue.

Is that sort of information available at product shipping time? In other words, when I buy the product when it hits the market, will such a search turn up anything? We know there are known bugs and workarounds since that's what this was all about, but is that information available right away? If you try that right now with "Visual FoxPro for Windows 8.0" to narrow it to version 8, how many articles do you get?

>I'm not trying to make it look like there is no time spent. There is. But, IMO, it is the normal time that is spent on debugging your application. This may be a large amount of time for some and not as much for others. It may be longer because there is an actual bug in VFP. I guess I attribute that to cost of doing business. I have run into it a lot more working with Oracle than I ever did working with VFP.

I hear what you're saying, but if I spend time debugging perfectly good code because of a bug that I don't know about in say, VFP, then that is not normal time spent debugging. It's additional time.

>Personally, I think I have only run into one new bug in the production product. In VFP 6, you could not use GETOBJECT() with the Windows Management Instrumentation. I spent a longer than usual time debugging something I was working on because it wasn't working and I thought it should. I finally reported it and it did get corrected in VFP 7.
>
>What would you do if Technet (that's what support.microsoft.com is) relating to VFP were shipped with VFP? How would you use it? Would you attempt to debug your application the same way you do now? If it didn't come around, would you then search the known issues listing? How is that different than what is supplied today via the web interface?

I would read it up front the same as the What's new information. By the same token, why ship the "issues" information if it's available on line? MS ships information about what's changed, and what issues there are in going from one version to another. In light of that, I don't see the sense in an argument against also including known bug and workaround information.

If people read the information that does ship, would be have a hundred questions about why 'group by' no longer 'works'? At least that information was there. All I'm contending is that if they feel it's right to ship some of the information that is going to make my life easier, then why not all of it?

>This started out as an execise in why buggy software is shipped. Buggy software is shipped for valid, IMO, reasons. It's done by every company that ships a non-trivial application to a significant (read relatively large) user base. You can't get around it. Some part of your application is not going to perform to specs for all your users. Users are dynamic. Data is dynamic. Put those two together and you get bugs eventually. If you interface with other systems, you get to buggy faster.

I agree on that. Software development is certainly not an exact science, and bugs get shipped. Although I cannot remember a situation when I shipped a known bug.

>I have shipped buggy software (I hear the gasps). Bugs have been reported/found during the testing phase of development. If they are bugs that I can reproduce in the production system, it means I didn't introduce them with this new version and most likely they won't get fixed. They have to affect a significant user base as well as affect an integral part of the system to hold up release. In case, you're wondering, some have been that significant and they were included.
>
>While I don't like to ship software with known bugs from previous versions, I have also done that. Some bugs are deemed such a low priority and it requires such a large change to what's already there, that during the evalaution process for the next release, it doesn't get selected. The one or two users that the bug affects may string me up and curse my entire family but the bug only affects them and in the grand scheme of things, satisfying 698 out of 700 users works for me.

Is the software you ship development software, or application software? I think it makes a difference.

Alan

>>I'm not talking about consultation. Just distribution of information. When I buy the product, what reasonable excuse is there for not giving me all the information about that product. If there are known bugs and workarounds, then that information should ship with the product. When I hit a snag, I have no idea, until I've spent time on it whether it's a bug in the product, a bug in my own code, or a by design issue that maybe I don't particularly like but will live with. If it's a bug in the software already known to the producer, then I've been forced by lack of up-front information into wasting my time.
>>
>>You make it sound like no time need be spent. Hit a snag, must be a bug, check the KB, done.
>>
>>How do you decide something is a bug without spending any time on it? And once you realize it must be a bug and check the KB, do you not feel at all that it's been time wasted?
>>
>>I still contend that shipping known bug and known workaround information with the product would reduce the amount of end user wasted time. Why should shipping the information be considered anathema to the producer?
>>
>>That is what I mean about our not being in the equation.
>>
>>

lFix = IIF(nPriority/nEstTimeToFix < 1, .F., .T.)

>>
>>so instead, how about:
>>
>>

lFix = IIF((nPriority/nEstTimeToFix) * nEstUserWasteTime < 1, .F., .T.)
>>
>>If !lFix
>>   lShipInfo = .T.
>>Endif

>>
>>Alan