Ken,

It's a dilemma, I guess. I understand your POV and actually surmised it. That's why I asked you what you'd think about a bug list initiative. Re: VFP Bug list seems to dry up Thread #989551 Message #992550. It would give you a chance to give a warning.

The problem with a non-MS bug list, for example here on the UT, is that such a list too can become a weapon in the hands of those who have a prejudice with regard to vfp. On the other hand, there IS a need for such a list. This need is felt at least by a subset of us. There have been some threads here in the past that made clear to me that some encounter a bug only incidentally, whereas others say they encounter them each working day. The first group appears to think that the second group consists of clumsy developers, and the second group appears to think that the first group consists of developers who only seldom try other aspects of vfp than they're accustomed to.

Personally I find bugs and 'by-design' quirks regularly, esspecially when experimenting. Years ago I would get upset. Nowadays I simply restart (in case of a crasher), try to find out the specific circumstance, think of a workaround and document it at the place of the workaround. No longer I get upset. I regard it as a fact of life. But what remains is - and that's important here - that, when being confronted with the quirk, I absolutely need the feedback of the community to answer the following questions:
- What I'm experiencing, is it really a bug? Or could it be that I do not fully understand the vfp model?
- The workaround I'm preparing, is it really the best solution? Or has someone else already created a workaround?
In my eyes, part of the community is the VFPTeam and since they have access to certain info that's not available to others, their feedback is highly appreciated.

When being confronted with a quirk, analyzing the conditions and creating a workaround is almost always (very) time consuming. The better the feedback from the community, the less time is lost on this non-productive activity. Also, high quality feedback lowers the frustation level significantly.

Having argued that a list is important for the serious developer, and acknowledging that such a list can be abused by prejudiced others, I propose that we try another perspective. Why not create a list of exceptional situations that produce unexpected results, which are sometimes simply bugs, other times quirks in the eyes of some and eventually by-design features that perhaps need some additional explanation? The key point here is exceptional situations. This should make it clear to prejudiced others that such a list can hardly be used for a serious attack on VFP.


>Hi Russell (and Jim and all),
>
>Let me be very open and clear about this issue. The primary reason we do not publish the complete bug list for VFP is that if we did, it may impact the sales of VFP. While almost all the existing bugs we know about only impact only one customer who found it, there are enough small bugs like this that add up to make it appear there are many problems when in fact the product is super stable and most people never even experience any significant problems - and if they did we release a hotfix, service pack, whatever is needed.
>
>The second reason we don't release the list is that it would take a significant amount of time to do so since we would have to go through all our bugs and format them removing some comments since some parts of our comments in the bug we would want to expose and others we wouldn't (either confidential information, cursing, and other non-essential details). That effort would be significant, taking time away from other priorities we are working on. On the other side and we want to be more transparent as a company and disclose more and more information to developers. But at this time, sales of VFP are more important than releasing a VFP bug list.
>
>The VFP team could do release the entire bug list if we wanted to with the above sacrifices, but at this time we are choosing not to (it has nothing to do with a company policy). You may or may not agree with this rationalization, but I figure you may appreciate a very direct and honest response to this request rather than just a "no". Hope this at least clarifies our position on this.