Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)

[Ben Rubinstein]

On 22/06/2010 16:01, Wilhelm Sanke wrote:
> It is as yet unknown whether during his stay in Edinburgh the new
> professor had come into contact with Revolution or the Revolution team,
> but considering the topic of his work this seems to be highly probable.
> Apparently he had taken a look at the Revolution bug database with its
> enormous lags in fixing even fatal bugs,  e.g. Report #8275 "Groups:
> Bugs and features ("last group" broken)?" of  Sept 16, 2009, which
> astonishingly is still listed as "unconfirmed" although it contains a
> recipe to crash Revolution with only 4 lines of script.

Wilhelm,

I share your frustration with bug reports remaining uncomfirmed for long 
periods, although I also agree with others (and perhaps you) that an 
absolutist approach of no-new-features-until-every-bug-is-fixed is not sensible.

However, taking a look at the report you mention, #8275, I can't find the 
recipe for crashing Revolution with only 4 lines of script.  There are 
references in that report, to another report "How to reliably crash Rev 3.5 
and 4.0-dp3 with four script lines", but from various searches in Bugzilla I 
am unable to find it.  Can you give me the report number?

Many thanks,

Ben

PS Thank you for taking the trouble to report issues in Bugzilla as I know it 
takes effort and it is a service to the community.  But I would recommend, to 
get the maximum value in return for your trouble, creating separate reports 
for each issue so that each can be understood as simply as possible, rather 
than creating one very long report that ties together several issues. 
Combining many issues in one report makes it hard for the developers to 
confirm, respond to, or fix any of the elements individually. For example in 
the report #8275: your item 1 describes a bug (which you mention may be 
related to a crash) which I can't reproduce, so the bug may or may not have 
been fixed; your item 2 describes some behaviour which is probably a feature 
(I've made use of it in the past, though for the unwary it could be a trap); 
item 3 is a feature request (one I happen to disagree with); your item 4 may 
be a bug or a feature, but if it is a bug it is one with an easy workaround; 
your item 5 apparently describes a crashing bug, but is an incomplete recipe. 
  The entire report is set with the severity 'blocker' ("Blocks development 
and/or testing work") - but only item 5 could possibly fit that description 
(you give a workaround for item 1).