hair-pulling frustration

[Richard Gaskin]

Dr. Hawkins wrote:

> On Tue, Nov 11, 2014 at 1:34 PM, Richard Gaskin wrote:
>> I'd like to raise these concerns with Ben and Kevin at my next 
>> meeting.
>> It would be very helpful if you could point me to the bug reports that
>> describe these issues.
> 
> That's the problem.  These are at a level that never should have seen
> the outside to be reported as bugs.

Hard to say without knowing what the specific issue is.

Peter's investigating the SQLite issue (thanks, Peter), and that may be 
a regression in LiveCode or it may be a change in SQLite itself.  There 
are many changes logged for SQLite in recent builds, so hopefully 
Peter's analysis will help shed some light on that.

Any other specific issues you feel are show-stoppers may well be worth 
looking into, and I'd be happy to help if I can.  But to do that I'd 
need to know what they are.


> That something unusual happens under certain circumstances is a bug.
> That the IDE window regularly pauses for seconds at a time, or stops
> taking input, is impossible to not notice if you actually use it.

Have you considered the possibility that things your app uses regularly 
may not be used as often by others?


> This is a commercial product that was released without testing;

I think the hundreds of testers who put in thousands of hours testing 
over the last 8 months would disagree.


> *that* the paying customers are expected to file bug reports over what
> should have been done before is the fundamental problem.

No one's obliged to test.  If having bugs fixed isn't of interest, 
there's no need to let anyone know when you find them.

If you prefer to wait until after release to find out if a build will 
suit your app's needs, any issues you find will, by definition, be 
post-release, and can only be addressed in yet another build later in 
the future.

It's a choice we make with complete freedom, with any software, or any 
product, according to our own needs for such assessment.

I never bother reporting bugs for software I don't rely on.  But I never 
buy a car without driving it several miles first.


> I have, however, added bugs 13997-9 about the failures of the 
> checkpoints
> in the IDE

I saw that - thanks for filing the report.  I'm sure by now you got 
notice that the lead engineer began researching it within 48 hours after 
you'd submitted it.

I suspect this will soon join the other 1,700 reported issues that were 
fixed over the last year, now that it's been brought to their attention.

This particular bug makes a good case study for the nature of testing in 
all software, whether it's LiveCode, or our own, or Apple's, or anyone 
else's:

A given issue may seem obvious if it's something your app uses 
regularly, but it's worth noting that after 8 months of testing by 
hundreds of community members in addition to internal resources both 
human and automated at RunRev, this issue had never before been 
reported.  I'd never seen it, nor heard anyone mention anything like it. 
  And eight months is a long time.

This is one of the tricky things about complex systems:  with so many 
thousands of tokens that can be combined and recombined in nearly 
infinite variety, the likelihood that the specific intersection of 
features a given app needs will be easily found by others simply can't 
be assured.

If you want to use a new version, it can help you get any issues that 
need resolving done before release if you choose to try the pre-release 
builds.

No one's required to test.  But many of us choose to do so because it 
benefits our own goals.

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org