[OT] Computer news from Kassel

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[OT] Computer news from Kassel

sanke
1. People around Kassel - and elsewhere - today celebrate the 100th
birthday of Konrad Zuse, the inventor of the first programmable computer.

Some extracts from Wikipedia:

"Konrad Zuse ( 22 June 1910) was a German engineer and computer pioneer.

His greatest achievem was the world's first functional
program-controlled Turing-complete computer, the Z3, in 1941 (the
program was stored on a punched tape).

Zuse also designed the first high-level programming language,
Plankalk├╝l, first published in 1948."

Zuse developed his computer living in a small town near Kassel. His
Z3-Computer is one of the exhibits in the "Technikmuseum" of Kassel.


2. The University of Kassel this semester added another position of a
"Junior Professor" in "Computational Sciences" to the faculty of its
IT-Department.

The first holder of this position got his doctorate at the University of
Edinburgh. His special field in research and teaching is "The structure
of programming - trouble-shooting and avoidance".

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.

Although this report is now almost one year old, apparently nobody from
Revolution so far has bothered to take a look at this bug report. It
might be a wise move from the side of the Revolution team to enlist the
support and cooperation of our new professor.--

Best regards,

Wilhelm Sanke


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Peter Alcibiades
The price of doing some things well, if you are a company with limited resources, is refusing to do everything badly.  

Or put it the other way, the price of trying to do too much is that you will not do anything properly or well.  In the end, this is company wrecking.  Its a life and death issue.

If Rev is really as overstretched as it looks, the first step is to close down some stuff until they arrive at a smaller set of things that can be done properly and to quality standards.  

If you can't fix the bugs in what you have, don't try to introduce more products, as you will then be unable to fix the bugs in them also.  In the common phrase, when in a hole, stop digging.

A common reaction to this situation is to deny it exists.  This is one of the clearest symptoms of the illness.  The cure begins with acceptance and acknowledgment of the problem.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

slylabs13
To some extent you have a point, but software bugs are a bit trickier. What some people call bugs are really not. Some bugs are extremely obscure, and only affect a very small number of people. Some bugs have a workaround, and so are not critical. For a company to devote all their resources to resolving these kinds of bugs is NOT good business, ESPECIALLY when the sales model is subscription based. People want to see at least one good release each year because they are paying for free upgrades.

I recall an old saying that there's no such thing as bug free software. Or to put it another way, to try and make software bug free would cost too much.

Bob


On Jun 22, 2010, at 8:31 PM, Peter Alcibiades wrote:

>
> The price of doing some things well, if you are a company with limited
> resources, is refusing to do everything badly.  
>
> Or put it the other way, the price of trying to do too much is that you will
> not do anything properly or well.  In the end, this is company wrecking.
> Its a life and death issue.
>
> If Rev is really as overstretched as it looks, the first step is to close
> down some stuff until they arrive at a smaller set of things that can be
> done properly and to quality standards.  
>
> If you can't fix the bugs in what you have, don't try to introduce more
> products, as you will then be unable to fix the bugs in them also.  In the
> common phrase, when in a hole, stop digging.
>
> A common reaction to this situation is to deny it exists.  This is one of
> the clearest symptoms of the illness.  The cure begins with acceptance and
> acknowledgment of the problem.
> --
> View this message in context: http://runtime-revolution.278305.n4.nabble.com/OT-Computer-news-from-Kassel-tp2264252p2265064.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Jeffrey Massung
On Wed, Jun 23, 2010 at 11:07 AM, Bob Sneidar <[hidden email]> wrote:


> [...] they are paying for free upgrades.
>
>
I'm sorry. I laughed out loud when I read that. Talk about the definition of
an oxymoron. ;-)

Jeff M.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

slylabs13
Heh heh. Listen to what I mean, not what I say. ;-)

Bob


On Jun 23, 2010, at 9:13 AM, Jeff Massung wrote:

> On Wed, Jun 23, 2010 at 11:07 AM, Bob Sneidar <[hidden email]> wrote:
>
>
>> [...] they are paying for free upgrades.
>>
>>
> I'm sorry. I laughed out loud when I read that. Talk about the definition of
> an oxymoron. ;-)
>
> Jeff M.
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Hugh Senior-2
In reply to this post by sanke
On budget
On time
Bug free

Pick any two.

/H
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

mwieder
Hugh-

Wednesday, June 23, 2010, 10:07:57 AM, you wrote:

> On budget
> On time
> Bug free

> Pick any two.

I have enough trouble just picking *one*...

--
-Mark Wieder
 [hidden email]

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Andre Garzia-3
On Wed, Jun 23, 2010 at 2:16 PM, Mark Wieder <[hidden email]> wrote:

> Hugh-
>
> Wednesday, June 23, 2010, 10:07:57 AM, you wrote:
>
> > On budget
> > On time
> > Bug free
>
> > Pick any two.
>
> I have enough trouble just picking *one*...
>

I've mixed them and end up picking budget free...



>
> --
> -Mark Wieder
>  [hidden email]
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



--
http://www.andregarzia.com All We Do Is Code.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

sanke
In reply to this post by sanke
I am very much aware of the fact that software is almost never bug-free.

Apart from the first part - where I wanted to direct your attention to
the computer pioneer Konrad Zuse - the rest of my post was written with
some degree of  tongue-in-cheek (both in its positive and negative
denotations), which some of you may have overlooked.

Also, I consider it an ironic coincidence in itself that we have got a
new colleague with a doctorate from Edinburgh University that
specializes in software trouble-shooting.-

I have been less complaining that there are bugs in Revolution, the main
point was my irritation that a bug report can still be listed as
"unconfirmed" after 9 months. What use is a bug database when it is
looked at only selectively? And in case described bugs could not be
replicated then I expect some follow-up communication from the side of
the Rev team.

For your convinience I re-quote my post below.

Regards,

Wilhelm Sanke

===========================================

> 1. People around Kassel - and elsewhere - today celebrate the 100th
> birthday of Konrad Zuse, the inventor of the first programmable computer.
>
> Some extracts from Wikipedia:
>
> "Konrad Zuse ( 22 June 1910) was a German engineer and computer pioneer.
>
> His greatest achievem was the world's first functional
> program-controlled Turing-complete computer, the Z3, in 1941 (the
> program was stored on a punched tape).
>
> Zuse also designed the first high-level programming language,
> Plankalk├╝l, first published in 1948."
>
> Zuse developed his computer living in a small town near Kassel. His
> Z3-Computer is one of the exhibits in the "Technikmuseum" of Kassel.
>
>
> 2. The University of Kassel this semester added another position of a
> "Junior Professor" in "Computational Sciences" to the faculty of its
> IT-Department.
>
> The first holder of this position got his doctorate at the University
> of Edinburgh. His special field in research and teaching is "The
> structure of programming - trouble-shooting and avoidance".
>
> 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.
>
> Although this report is now almost one year old, apparently nobody
> from Revolution so far has bothered to take a look at this bug report.
> It might be a wise move from the side of the Revolution team to enlist
> the support and cooperation of our new professor.--

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Andre Garzia-3
On Wed, Jun 23, 2010 at 4:33 PM, Wilhelm Sanke <[hidden email]>wrote:

> I am very much aware of the fact that software is almost never bug-free.
>

It is not that software is never bug-free... software is only ready when it
is bug free, the problem is that software is never ready (or at least I used
to repeat that to Dan Shafer while in Monterey).

:D




--
http://www.andregarzia.com All We Do Is Code.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Peter Alcibiades
In reply to this post by Hugh Senior-2
The most dangerous argument any company can entertain on this subject.  The question is, how the company handles reported product defects, what sort of quality control it operates, whether the result of its resource allocations is to end up doing many things badly, because it has taken on too much.

Does the fact, and it probably is one, that you can fix time, cost or quality, but not all three at once, mean that its OK to have reported bugs hanging around for years at a time undealt with?  Not necessarily unfixed, but not dealt with and disposed of one way or another?  No.  In the end that is the route to failure.  

Do whatever you do to appropriate and justifiable quality standards, and if that means you have no resources left for the new products you would like to introduce, tough.  Because you are not going to succeed as a company by introducing them at the expense of overall quality, anyway.  There is no better alternative on this than doing what you do, right.  And not doing the things you do not have the resources to do right.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

David C.
> Because you are not going to succeed as a company by
> introducing them at the expense of overall quality, anyway.

Maybe someone forgot to explain that to a little outfit called Microsoft...
They seem to have succeeded "pretty well" over the years, publishing
products with thousands upon thousands of known bugs, not to mention
the all too often sub-standard quality.

A company that would forfeit the introduction of new ideas and
innovation in a highly competitive arena, just so they can "perfect"
an already successful product, seems like a sure fire path to failure
to me.

Seems to be less than a smart business strategy, IMO.

Best regards,
David C.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

slylabs13
In reply to this post by Peter Alcibiades
Again, we are using the word "bugs" here on a one dimensional sense, as though all bugs were created equal. Is it reasonable to expect Adobe to fix a bug that deselects an object when I alt-shift-control-right-click on a menu? No, it's not. Is it reasonable to expect them to fix it when it crashes to desktop corrupting the file I had open? Absolutely. If we are going to have any kind of honest discussion about the subject, we have to make this distinction.

Also, many bugs are not fixed or dealt with in the minor releases, but are addresses in the major ones. I find that entirely reasonable as well.

Bob


On Jun 24, 2010, at 1:55 AM, Peter Alcibiades wrote:

> Does the fact, and it probably is one, that you can fix time, cost or
> quality, but not all three at once, mean that its OK to have reported bugs
> hanging around for years at a time undealt with?  Not necessarily unfixed,
> but not dealt with and disposed of one way or another?  No.  In the end that
> is the route to failure.  

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Richmond Mathewson-2
In reply to this post by David C.
On 06/24/2010 03:31 PM, David C. wrote:

>> Because you are not going to succeed as a company by
>> introducing them at the expense of overall quality, anyway.
>>      
> Maybe someone forgot to explain that to a little outfit called Microsoft...
> They seem to have succeeded "pretty well" over the years, publishing
> products with thousands upon thousands of known bugs, not to mention
> the all too often sub-standard quality.
>
> A company that would forfeit the introduction of new ideas and
> innovation in a highly competitive arena, just so they can "perfect"
> an already successful product, seems like a sure fire path to failure
> to me.
>    

These types of discussions can go on and on forever; but they are really
caused by
the fact that RunRev have given many users the impression that they are
"not JUST
a commercial company" (and to a certain extent that is true); this has
led many
people (myself included) to expect that because RunRev does takes its
existing
customers' opinions into consideration, it won't behave like a
commercial company.

Now the hard, couldn't give a ##### for your feelings company,

and more customer-friendly ones (such as RunRev) run by businessmen with
consciences, are different beasts; notwithstanding that, they are both
businesses that, at the end of the day, have to worry about how to pay for
the bread and cheese, the next patch of R-and-D, and keep their shareholders
happy.

The road to hell is paved with good intentions; and normally those
intentions
are of the altruistic kind.

The "new" Apple OS and its WIMP GUI is 'still' a horrible mess and is
only reasonably
intuitive because we have grown up with the thing. Apple made a lot of
ballyhoo about
Snow Leopard; but not to sort out the GUI; but to slim down their code
so that the
system made systems look faster than they did when running the previous OS.

----------------------------------------------------------------------------------------------------------------------------

Frankly I'm glad I'm not working for RunRev (come to think of it, they're
probably extremely gald I'm not working for them . . . . kisses, Richmond);
because they must have all sorts of pressures impinging on them from all
directions.

I may be at least 10 years older than Kevin Miller; but I am sure he is more
likely to develop stress-related stomach ulcers than I am.

I fool around with my programs for funny Indian writing systems (and I find
that extremely mentally stimulating) and so far I have earned the princely
sum of 8 Euros because I am not dependent of the computer world for my
bread and cheese, and because in terms of programming I am answerable
to myself alone. Kevin Miller is right, slap-bang in the middle of a socking
great spider's web; a place I would not like to be; and perhaps, knowing
that we should be a little less hard on him and his company.

> Seems to be less than a smart business strategy, IMO.
>
> Best regards,
> David C.
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>    

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Computer news from Kassel

Richmond Mathewson-2
In reply to this post by slylabs13
On 06/24/2010 07:02 PM, Bob Sneidar wrote:
> Again, we are using the word "bugs" here on a one dimensional sense, as though all bugs were created equal. Is it reasonable to expect Adobe to fix a bug that deselects an object when I alt-shift-control-right-click on a menu? No, it's not. Is it reasonable to expect them to fix it when it crashes to desktop corrupting the file I had open? Absolutely. If we are going to have any kind of honest discussion about the subject, we have to make this distinction.
>
> Also, many bugs are not fixed or dealt with in the minor releases, but are addresses in the major ones. I find that entirely reasonable as well.
>
> Bob
>
>
>    

However, a problem that was found in RunRev 2.5 not having been fixed by
4.0 is a bit . . . . .
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Ben Rubinstein
In reply to this post by sanke
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

sanke
On Thu, 24 Jun 2010, Ben Rubinstein <[hidden email]> 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
>
> <http://www.sanke.org/Software/MoreAboutMasksRev3.zip> in the text
> brought up
> on the menu card from the topright introduction button.


Best regards,

Wilhelm Sanke
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Ben Rubinstein
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

J. Landman Gay
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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

sanke
In reply to this post by Ben Rubinstein
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"
<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>):

> "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 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)).
>
>
> 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
The crash occurs with version 4.5.0 dp3, too, like with the older versions.

I'll think about your proposal, although I believe all the information
needed was supplied by me - maybe not in an optimal order or structure -
but in a form sufficient to elicit at least a timely feedback.

Regards,

Wilhelm
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution