Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On Fri Jun 25, 2010, Ben Rubinstein benr_mc at cogapp.com wrote:
On 25/06/2010 17:36, Wilhelm Sanke wrote:
> And, if someone finds out that "you can crash Rev with
> only four lines of script" this should definitely arouse the attention
> of the responsible members of the Rev team, irrespective whether the bug
> report is multi-faceted or concentrated on one single sub-point. The Rev
> team should be competent enough to deal with a number of related
> troubles at the same time, or deal with them step by step. I believe
> that they are basically capable to handle also complicated issues, they
> are not first-graders in computer science.
But they are busy people, who have to choose where to put their time.
So are we!. My time is equally valuable. I think the relationship
between the Rev team and their customers, supporters, cooperators etc.
is one of mutual acknowledgement and respect without any trace of a
hierarchy.
I believe the unresponsiveness of the people from Rev in this case - an
unresponsiveness which happily does not happen all the time, I indeed
did have quite a number of normal and positive experiences - is mainly
an organisational problem.
If you set up a bug database for Rev users, you have also to develop
regular procedures to communicate with the sender of a bug report in a
narrow time frame. If there are open questions concerning a report -
facts and arguments that may be totally clear in the mind of the sender,
but actually need extra clarifications and additional information for
the member of the Rev team that is assigned to the bug - then there is
the need (and there should be the time) to contact the sender about it.
Just staying mute for 9 months, doing nothing, is not appropriate and
helpful - and certainly counterproductive to the goals of further
development and improvement of Revolution and establishing a good
working relationship with its users.
I took
some time to work through the bug, which is actually called "Groups:
Bugs and
features ("last group" broken)?". It refers to a way of crashing Rev,
but
doesn't give enough information. I tried, yesterday, to reproduce the
bug
using the script fragment in the bug report, but without success.
However,
that may be because I didn't know the definition of 'pre-PNG'. Perhaps
I would
have discovered that by following the clue of "my recent post to this
list",
but that was more time than I had. I tried with a PNG, and it didn't
crash.
As I had stated in the bug report, the crash occurs with what I have
called and defined as "Pre-PNGs", PNG images created inside Revolution,
but apparently differing from PNGs created with other image tools. This
in itself may be a bug.
I will quote here from the relevant links for the definition of Pre-PNGs
which I had supplied in my bug report (My post to the use-revolution
list "How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines"
of August 26, 2009, and the introduction to stack "More about Masks"
):
"Pre-PNG" images are basically those that are created or modified (as
to their imagedata) in Revolution and have not yet been saved as
external files and then been re-imported. Even if you export a
snapshot using "to image x as PNG" (image x being an image already
existing on the card), the resulting image will remain a Pre-PNG, also
copying and pasting the Pre-PNG to another card or stack preserves the
quality of the Pre-PNGs which behave differently in some respects. For
details see my comments in "More about Masks".
From the introduction to stack "More about Masks":
A final observation concerning the creation of masks inside Revolution
and using the "import snapshot" format:
If the resulting mask image is not first saved as an external file and
then imported again, meaning if it remains as freshly created inside a
stack or was just copied from another mask-producing stack, then this
mask image will have a different quality, which we might call a "pre-PNG".
Pre-PNGs behave somewhat differently than normal PNGs: You cannot
transfer its alphamask to the image-to-be-masked when the pre-PNG is
hidden, at least not several times with resizing. After you have
resized a pre-PNG during the masking process, you might find that it
is suddenly "empty", but it can be restored when you copy and paste it
(it then appears in its original size and shape).
A workaround to overcome this problem is to store the mask in a custom
property of its own and then to "initialize" the mask each time before
it is used in the calling script:
"put the CPimg of img "transition" into img "transition""
But of course you can easily convert a pre-PNG to a full PNG by saving
the image as an external file.
There are more peculiarities of these Pre-PNGs than I have described here.
Again, I share your frustration that reports can be left 'unconfirmed'
(and
for much longer than a year - my o
Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
Ben Rubinstein wrote: (I also know that some bugs have been fixed although the entry in Bugzilla hasn't been addressed. That may be because the bug was found independantly either by RR directly or because of a duplicate report, and it's just annoying that they've never noticed my report; or it may be that someone read my report, fixed the bug, but for some reason didn't follow the process to resolve it.) That happens more than we'd like, actually. They fix stuff and then forget to update the database. Or they fix stuff they didn't know was in the database. I suppose we could complain about engineers who don't keep up with paperwork, but you know how that goes. I'm kind of like that myself. Thanks for a thoughtful post on writing effective bug reports. You made some good points. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On 25/06/2010 17:36, Wilhelm Sanke wrote:
One thought that led me to put together a more comprehensive report is
the assumption that at least some of the listed bugs are somehow related
to each other.
You can always create five separate reports, and then create a sixth one
suggesting that there are a nest of issues relating to groups, giving the id
of each. (Bugzilla is designed to support this kind of usage: if you refer to
"bug nnn" or "bug #nnn" in the text of the description or a comment it is
automatically recognised, and made into a link to the other bug report, with a
tool-tip giving the bug status and title.)
And, if someone finds out that "you can crash Rev with
only four lines of script" this should definitely arouse the attention
of the responsible members of the Rev team, irrespective whether the bug
report is multi-faceted or concentrated on one single sub-point. The Rev
team should be competent enough to deal with a number of related
troubles at the same time, or deal with them step by step. I believe
that they are basically capable to handle also complicated issues, they
are not first-graders in computer science.
But they are busy people, who have to choose where to put their time. I took
some time to work through the bug, which is actually called "Groups: Bugs and
features ("last group" broken)?". It refers to a way of crashing Rev, but
doesn't give enough information. I tried, yesterday, to reproduce the bug
using the script fragment in the bug report, but without success. However,
that may be because I didn't know the definition of 'pre-PNG'. Perhaps I would
have discovered that by following the clue of "my recent post to this list",
but that was more time than I had. I tried with a PNG, and it didn't crash.
Again, I share your frustration that reports can be left 'unconfirmed' (and
for much longer than a year - my oldest 'unconfirmed' bug report is more than
three years old, my oldest unconfirmed enhancement request more than six years
old! (and I still want it)).
But that's not to say that those guys aren't working. Of the reports I've
opened in Bugzilla over the years, 155 of them have been resolved - some as
duplicate, can't resolve, or not a bug, but the vast majority as fixed. That
leaves 34 unconfirmed, and 24 in the limbo state between unconfirmed and
resolved. That's not a great result: I'd much prefer things at least came off
the 'unconfirmed' list faster, even if they were then consigned to a black
hole of low priority; but it's not awful.
(I also know that some bugs have been fixed although the entry in Bugzilla
hasn't been addressed. That may be because the bug was found independantly
either by RR directly or because of a duplicate report, and it's just annoying
that they've never noticed my report; or it may be that someone read my
report, fixed the bug, but for some reason didn't follow the process to
resolve it.)
If you think that RR should be aware of this crashing bug, you would do them a
big favour by opening a report with the title you mention, with severity
'critical' or 'blocker' (if the latter can be justified), with the version
4.5.0 dp3 (having verified that the bug is still reproducible in the latest
version), and with _all the information that RR need to reproduce the bug in
one place_ (and as little other information to obscure that as possible). If
there's a particularly variety of PNG that is involved, please include all the
details needed to understand that in the bug report (as well as attaching a
sample image to the report).
Ben
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On Thu, 24 Jun 2010, Ben Rubinstein wrote:
On 22/06/2010 16:01, Wilhelm Sanke wrote:
> > 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.
Ben,
Thank you for looking into this matter. You are certainly right when you
recommend filing separate bug reports.
One thought that led me to put together a more comprehensive report is
the assumption that at least some of the listed bugs are somehow related
to each other. And, if someone finds out that "you can crash Rev with
only four lines of script" this should definitely arouse the attention
of the responsible members of the Rev team, irrespective whether the bug
report is multi-faceted or concentrated on one single sub-point. The Rev
team should be competent enough to deal with a number of related
troubles at the same time, or deal with them step by step. I believe
that they are basically capable to handle also complicated issues, they
are not first-graders in computer science.
There were 5 to 6 more sub-points concerning groups I was going to add
to that report, but I had waited for a first response - which never was
sent.up to now.
The four-liner is contained in point 5 of my bug report - see below -
and the post I mentioned there
"How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines"
was sent to the use-revolution list on August 26, 2009 - and can be
found in the archives.
5. Groups belong to the factors in an already reported scenario for safely
crashing Rev
I have described this in detail in my recent post to this list "How to
reliably
crash Rev 3.5 and 4.0-dp3 with four script lines". Here I just point
out that
"group" is among the elements causing to crash Rev and refer you to my
original
post for more details.
The following script assumes that you have set the angle of img "test"
to an
angle other than 0, that img "test" is ungrouped, and that img "Test"
belongs
in the category of "Pre-PNGs".
"lock screen
select img "Test"
group
set the angle of img "Test" to 0"
For the definition of "Pre-PNGs" see my above-mentioned post or the
introduction of my stack
in the text
brought up
on the menu card from the topright introduction button.
Best regards,
Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
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).
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
