Open Letter to Rev: Quality Is Job #1

J. Landman Gay jacque at hyperactivesw.com
Fri Oct 20 15:21:56 CDT 2006


Bill Marriott wrote:

> - The installer introduced in 2.7 is horrible. It installs desktop shortcuts 
> that point nowhere. The file associations are busted.

The team knows this (because someone posted it to Bugzilla) and is 
working on it.

> 
> - Standalones created with 2.7.x are bigger, slower, consume more resources, 
> and are highly unpredictable compared to standalones created with 2.6.1. 

There are more libraries and a new file format, as well as lots of 
additional features offering more control. This takes up more space and 
resources. I have not seen any change in speed of execution though; 
scripts seem to run just as fast.

I have experienced none of the problems you report with instability, so 
there is apparently an issue with something specific you are doing in 
your stacks that the rest of us don't see. Again, a bug report that 
could reproduce the problem would be welcome. Crashes are fixed first, 
with top priority.

> Half the time, quitting the standalone leaves the process running in Task 
> Manager -- when the exact same stack under 2.6.1 exits cleanly.

This, I believe, is a scripting issue on your part. Executables will not 
quit if a running process has not completed; this is documented 
behavior. I have never seen Revolution leave itself running in any of 
the stacks I'm writing under Windows, so I have to assume that you are 
leaving someething open. This could be a shell command that has not yet 
returned, an open library that is doing something, or a dll that has not 
been closed.

> We've had 
> reports of libraries not being included even when explicitly added.

See Trevor's comments on this list about this, where he identifies the 
problem specifically. You've had "reports" but have you had the 
experience yourself? It would seem to be a problem with the shell 
command on Mac OS X. Have you actually experienced this problem on Windows?

> And Bill 
> V's recent post is not the first report of standalones being built 
> incorrectly or bugs returning from the dead.

Perhaps, but I am more inclined to suspect that the wrong standalone 
engine crept into his Runtime folder somehow. No one else has mentioned 
any problems with it.

> 
> - More often than I'd like, quitting Rev 2.7.x itself results in an 
> application error upon exit. And that is if you're lucky and the process 
> isn't simply "hidden" as it is in standalones that don't quit properly.

See above, and check your scripts for uncompleted processes.

> When 
> the Windows Error Reporting dialog comes up I click "Send Report" every 
> time... do you guys even receive/read those reports? Because I haven't seen 
> any decrease in their frequency from one release to the next.

Runtime doesn't get these reports. The only way to be sure that the team 
sees your report is to enter it into Bugzilla. That is the one and only 
venue that assures the problem will be noticed. If you hate Bugzilla and 
can't stand to take the time to enter a report, then write one up in 
your own words and send it to <support at runrev.com>, along with any 
stacks that reproduce the issue, and I will enter it into Bugzilla for 
you. You will not get progress reports if you do that though; Bugzilla 
update notices are sent only to the original reporter.


> - The Internet library has resulted in lockups in stacks that have run 
> without incident under 2.6.1.
> 
> In fact, the 2.7.x series is so awfully bug-ridden, its most welcome new 
> feature is the ability to save in "legacy" format.

I've been using every version of 2.7 and haven't seen much of what you 
report. This again leads me to believe that you are scripting something 
specific that others don't generally use. That could be why so many 
people have no issues, but you are so frustrated. It is difficult to fix 
a bug you never see; that is why you should send copies of stacks that 
reproduce the problem to Bugzilla.

I had a similar experience about a year ago. I found the debugger to be 
entirely unusable. It simply would not work under any circumstances, and 
the internet library also failed. I was at a loss, and could not 
identify the problem, but no one else had any trouble with it.

Months later, I finally was able to pin down the fact that the debugger 
didn't work if the stack file path had a comma in it. This turned out to 
be the exact same problem that affected the internet library. I wrote to 
Dave Cragg and he had a fix for me within a single day. I reported the 
same thing to the team and the next release of Revolution had a fix in it.

The reason I'm telling you this story is because I want you to 
understand that I was as frustrated and unhappy as you are -- but I was 
aware enought to know I was the only one apparently affected. The 
debugger was completely, irretrievably broken for me, and yet no one 
else complained. The issue was easy to fix once I identified the cause, 
but completely unreproducible by anyone else.

The team does not expect you to identify the cause of bugs yourself, but 
giving them an example stack would sure be a better way to get things 
fixed than venting all over the list. That solves nothing.

> 
> Yes, Rev, it's really that bad.

For you. I haven't had any of the issues you describe. Tech support 
hasn't had any reports of most of what you describe (we did get the one 
about the installer. So they're working on it.) There are lots of people 
working with lots of copies of Rev and they don't have these problems 
either. The only logical conclusion is that your stacks do something 
that causes these issues, and if you can send them an example, the team 
can fix it. If you refuse to do that, and if no one else has the 
problems, then I guess you'll just have to stay frustrated because it 
will go unreported.

> 
> Some of you will say, "Bill it would be much more productive if you filed 
> all this in Bugzilla." Well, I'm all for contributing to the community. But 
> it takes time and effort to file a decent bug report. You need to have 
> something reproducible, supply sample files, write it up properly, etc. 

Yes, that's true. And if *you* can't provide a reproducible stack -- and 
you are the one having the trouble -- then how can the team do it? 
Obviously it worked for all their tests prior to release. What are they 
supposed to do to find the bug that you can't provide an example of?

> I haven't seen action on other serious bugs

"Serious" is a relative term, depending on who is using it. However, 
crashes are always fixed promptly.

> 
> Besides, I don't even "own" this version.

That doesn't matter. You can submit to Bugzilla even if you are just a 
trial user.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



More information about the use-livecode mailing list