Re: BDS 2006

On Sun, 24 Dec 2006 17:00:43 -0800, Dave Nottage [TeamB] wrote:

I've had a look at your post. Here are some comments:

QC31990, QC30402

It is listed as being resolved in build 10.0.2288.42451, ie post Update
2, probably in Highlander.

That is the build number for BDS 2006 update 2. QC is reporting these
issues as resolved in that build not in some subsequent build.

I'm not sure what you mean by the comment "no change to the code",
because a fix rarely involves no changes.

If you look at the 33 user reported issues, 13 were closed as duplicates
and marked as resolved in update 2. That means these 13 issues were
resolved without any change to the code base. If the reports that they
duplicated were resolved, they are counted separately. These 13 reports do
not count as 13 bugs that were corrected. Similar arguments apply to the 8
marked "can't reproduce", 3 "test case errors", 1 "need more info", 1 "as
designed", and 1 "won't do". They didn't change anything in the BDS code
base to resolve these reports. They simply marked them as resolved in
update 2, none of them are marked as fixed (resolved in v.s. resolution).
So 27 of the 33 user reported bugs that were marked as resolved by update
2 were not fixed in update 2. Borland/Codegear is only claiming that 6 of
these issues were fixed in update 2. The other 27 reports are not 27 more
bugs that were corrected, they are simply reports that were closed.


About supporting earlier versions: there has to be a limit on how far
back bug fixes are applied to. This might change (ie perhaps reach
further back) under CodeGear, though.

I'm not talking about supporting earlier versions. BDS 2006 is the
*current* version. It is one shipping now. It is the one they should be
releasing bug fixes for now, as they are found and fixed, rather
collecting them for a future release with a new version.

"Finally, to make matters worse the focus of development at Borland
seems to be adding new features (i.e. .NET) rather than fixing the
problems with the existing product. You really can't ride two horses at
the same time."

I really have to wonder about the validity of those statements. I can't
think of any serious developer who cannot do both.

I beg to differ. It is always a matter of priorities. The developers
(individual people) who are working on .Net feature, are *not* working on
finding and fixing BDS bugs. If Codegear placed a greater importance on
finding and fixing BDS bugs, they should be able to release several bug
fixes per month (if not per week). This would greatly increase the
stability and usability of BDS, but would require redirecting substantial
developer resources who are now working on other things (since, I assume
they aren't sitting around doing nothing).

Dennis Cote
.

Relevant Pages

  • Re: The Borland Vision: Wrong?
    ... > will, at the end of the day, resolve your problems? ... for it and address bugs and issue SPs. ... defence of Borland for not fixing bugs (in the thread 'QC in place to humour ... and applaud Borland for that rather than complain that other bugs developers ...
    (borland.public.delphi.non-technical)
  • Re: Problems w/ ADODB.Recordset as Report Source...
    ... be stored on the SQL Server. ... ADODB.Recordset in the reports OPEN event, ... Anyone have any idea what I'm missing and how I can resolve this? ...
    (comp.databases.ms-access)
  • Re: Article: Top 7 Ways A Knowledge Base Program Can Improve Your Office
    ... Knowledgebase Software by VUNET at http://www.vunet.us/home.asp ... - Case Management (Open, Assign, Resolve) ... Inventory Management ... Reports ...
    (sci.med.cardiology)
  • Re: French characters
    ... large organization using MS Access to create reports from a Oracle Data ... approach (but if I cannot resolve this then I must). ... I find it baffling that Impromptu can report the correct characters, ...
    (comp.databases.oracle.misc)
  • Re: QC in place to humour developers?
    ... >> fixed some of the other bugs'. ... > Borland on these newsgroups, in the face of overwhelming evidence to ... bugs rather than trying to address and resolve all bug reports seemed odd ...
    (borland.public.delphi.non-technical)