I posted a bug at the support centre that was changed to a "suggestion" while it clearly was a bug. And get this: it was immediately "implemented".
So it begs the question: Is DevExpress pushing for better support stats? Showing less bugs, but more implemented suggestions?

Which issue was it?


Brien King
President, ClassicSoft, LLC
http://www.classicsoft.com
brien@classicsoft.com
Developers Helping Developers!

FN> I posted a bug at the support centre that was changed to a
FN> "suggestion" while it clearly was a bug. And get this: it was
FN> immediately "implemented".
FN>
FN> So it begs the question: Is DevExpress pushing for better support
FN> stats? Showing less bugs, but more implemented suggestions?
FN>

I gave a link... but here is it in full URL: http://www.devexpress.com/issue=B131565

i wouldnt say that, maybe a Dev can explain it into more detail, but it sounds correct in the "by design" factor.  You just got lucky..

Using XPO should provide transparency regarding the DB provider that is used as the store, that is, it should work the same from one provider to the other (especially if it involves doing a simple select). So in the case of that issue you telling me that selecting something via XPO using MSSQL as the provider and doing the same select using MS Access, but providing a different result, is not a bug?

yes it should provide transparency, but not complete, there will ALWAYS be differences between each database provider IE MSSQL and Oracle, which will make these "issues" more "By Design" and will force DevExpress to implement a fix for a particular DB provider.

Hi Francois,

Indeed, I converted this bug report to a suggestion.  I did so because XPO was defined as follows:

if you have a delayed property and it was not loaded, this field value was not posted to the database. So, default field values appeared in the database.  Thus, the behavior described in your original message was the designed behavior and we considered it to be correct.

We discussed this behavior and decided to change it.  This is how this happened. So, we do not try to get a better stats by converting bug reports to suggestions ...

There is nice post by Jeff Atwood about suggestions vs bugs:

http://www.codinghorror.com/blog/archives/001189.html

Cheers

"Przemyslaw Wlodarczak" wrote in message news:242292@community.devexpress.com...

There is nice post by Jeff Atwood about suggestions vs bugs:

http://www..codinghorror.com/blog/archives/001189.html

Cheers

---

http://community.devexpress.com//forums/p/71082/242292.aspx#242292

Valid points Trevor.

IMHO there should be some kind of bug / suggestion categories, but only internal:

• For all people outside dev team it is not so important. Customer only cares that something should be done, because it prevents him from accomplishing his tasks. He does not care much what the root of his problem is: bug in current implementation, strange design or lack of feature.
• Only developer can distinguish whether particular issue is in fact bug in his implementation or missing functionality. It is because only dev knows all rationale behind current implementation.

I think second point can explain some "weird" changes from bug to suggestion.

Trevor Westerdahl:

Should a bug get priority over a suggestion simply because of the category?

IMO yes, this should be the case for issues that are confirmed by dev to be bugs. "Zero bug tolerance" principle is very important to keep codebase in healthy state.

Cheers

Trevor Westerdahl:

So, if I understood, don’t distinguish between a bug or a suggestion?

Not exactly.

A bug represents code that breaks a specifically designed and documented function or sub-function. Code is not considered a bug if it simply does not work as the user (or world) expects, especially if DevEx has not previously specified or documented the functionality. In this case, the code was doing exactly what it was supposed to do (as it was designed) even though it is "wrong". So your bug was changed to the correct "suggestion" for improvement.

Linton