hair-pulling frustration

Richmond richmondmathewson at gmail.com
Tue Nov 11 16:26:16 EST 2014


On 11/11/14 23:16, Richard Gaskin wrote:
> Richmond wrote:
>
>> On 11/11/14 21:55, Richard Gaskin wrote:
>>> I agree, which is why it benefits no one more than ourselves to test
>>> our work with pre-release versions.
>>
>> That is, of course, very true.
>>
>> Another idea that might not be bad, is to slow down the releases so
>> there is more time for testing.
>
> Agreed.  While v7 did have an unusually long test period as it was 
> (first test build was release March 19), there are a couple rough 
> edges in the "Stable" build that seem the sort of thing that might 
> have been handled prior to that designation.
>
>
>> I would love to do more testing (I do almost none) but do not have
>> the time as I have a full work schedule both in terms of my
>> teaching duties and my programming ones.
>
> True, we can only afford the time we can afford.  Unicode's not very 
> critical for my work, so most of my testing was with v6.7, testing v7 
> only on Ubuntu and really only focused on the new Linux-specific 
> additions there.
>
> But when a given version has new features that seem useful to us, 
> testing is critical to ensure that it'll do what we want to it do when 
> the final build comes out.
>
> And testing needn't necessarily be all that deep.  LiveCode has a lot 
> going on, arguably more akin to an OS than to any consumer app.  We 
> all do different things with it, and no one can guess the exact 
> interaction of language elements we'll be using in our own scripts.
>
> So while we can't be expected to test everything, if we only test our 
> own apps with new builds that's usually all we need for our own work.  
> Collectively, if we call just ensured that new features get 
> implemented in ways we need, we'll all have what we want.
>
> Rather than thinking about testing LiveCode, big as it is, it may be 
> more helpful to think of it as testing you own app's functionality in 
> the sliver of LiveCode that it uses.  Just test your own stuff, and 
> your own needs will be addressed.
>
>
>> Another idea would be to award "brownie points" to anyone who identifies
>> and documents a bug, and, after somebody has collected
>> enough points they could receive some sort tangible reward.
>
> That's a good idea, and one I know Ben is keenly interested in 
> persuing.  In fact, he's brought it up in a couple of our Community 
> meetings, but maybe you can help us out with some of the details we've 
> been stuck on:
>
> What sorts of perks would you find motivating, and at what level of 
> testing effort or bug report count should they kick in?
>

How about a series of T-shirts with insects all over them and the 
LiveCode logo: and the words, "I've helped squash X bugs." where 'X' is 
a number?

Fairly childish, but fun and effective!

Richmond.




More information about the use-livecode mailing list