On 7 May 2001, at 15:32, Jason Wharton wrote:

> Use the current version of 3.6De. It is by far the most stable version
> of IBO yet. It is true that I have goofed by missing a file in the
> sub-release zips now and then but the code's workings have done
> nothing but get more solid over time. I have been in solidification
> mode with 3.6 for months now as new development has all been going
> into a separate version.

As long as humans write code, there are goofs, the real telling
point, is how quickly those goofs are discovered, and how quickly
they are fixed. The missing .res file in 3.6.Dd was discovered
almost immediately, but it was a week before it was fixed. If I
didn't backup the IBO directory, before installing 3.6.Dd then I
would have been dead in the water for that week. The actual .res
file could have been posted on the download site on it's own, when it
was discovered. Mind you this isn't bad, there are bugs in Windows
that languish for six months before the next service pack.

> Under your definition of stable you are asking me when am I going to
> stop developing IBO. The answer to that is, I'm not. While I wish I
> was absolutely perfect in how I make IBO, I am human and bugs come up
> from time to time. The fact that I tend to magnify them instead of
> sweeping them under the rug is discomforting to people but I'd rather
> people perceive more bugs and have less than for people to perceive
> less and have more.
>

I like the idea, that you tend to be open about bugs, and bug fixes,
every bug that gets identified, is a heads-up, on a potential
problem. If you work with critical projects, then every potential
problem identified and fixed, is another 2:30am on a Saturday call
that doesn't get made.

What is sometimes a problem, is that it's clear about discovered
bugs, but not always so clear about when they get fixed. I have a
possible solution for this. A database, all it needs is one table:

CREATE TABLE BUGLIST(
BUG_ID INTEGER, /* Hooked to a generator */
DISCOVERED_IN VARCHAR(10), /* version number where discovered */
DISCOVERED_BY VARCHAR(50) /* email of person first discovered */
VERIFIED_BY VARCHAR(50) /* email of person who verified it as a bug
*/
STATUS VARCHAR(10) /* Reported, Open, fixed, disappeared, etc */
FIXED_VERSION VARCHAR(10), /* version fixed in */
COMMENTS BLOB SUB_TYPE 1 /* comments on bug could also be a varchar
*/
}

This database then gets gbak'd and the backup gets put into each
release. A small demo app could be written that allows the user to
search this database. You might also make the backup available as a
seperate download.

When someone reports a bug, it gets added to the database, you can
then verify whether it's a bug in IBO, or something else. I included
the discovered by, because someone who has questions about this bug,
can ask the person who discovered it.

> Perhaps I shouldn't ask but... Is there anyone else out there who
> feels the same as Hans or is he being overly critical?

I think he is being a little over critical, especially when it's
uncommon that SVs even acknowledge bugs of any kind. However if he
works on projects where software problems need to be fixed in 30
minutes or less, even if it is 3:47am on a Sunday morning, because
the company who uses it is dead without it. Then he has a right to
be critical.

Paul


Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com