Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
benr_mc at cogapp.com
Thu Jun 24 15:09:06 EDT 2010
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.
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?
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).
More information about the Use-livecode