 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When I did software testing for one of the UK high street banks we had a
theory about software bugs. We reckoned that the rate of fixing bugs in
a complex piece of software was approximately linear, but the rate of
finding new bugs decreases because there should be fewer bugs to find
(as long as the attempted bug fixes didn't introduce more new bugs as
side effects). By observing the way the number of known outstanding bugs
decreased over time, we considered it possible to estimate the probable
number of unknown bugs remaining in the system.
So here's the numbers of outstanding confirmed bugs from the various
known bug lists.
Date known bugs
---- ----------
27 Sep 19
28 Sep 16
1 Oct 21
23 Oct 25
1 Nov 27
21 Nov 38
27 Nov 42
2 Dec 37
current 42 (list not yet published)
We appear to be moving in the wrong direction.
(That never happened at the bank.)
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <425### [at] econym demoncouk> , Mike Williams
<mik### [at] nospamplease> wrote:
> When I did software testing for one of the UK high street banks we had a
> theory about software bugs. We reckoned that the rate of fixing bugs in
> a complex piece of software was approximately linear, but the rate of
> finding new bugs decreases because there should be fewer bugs to find
> (as long as the attempted bug fixes didn't introduce more new bugs as
> side effects). By observing the way the number of known outstanding bugs
> decreased over time, we considered it possible to estimate the probable
> number of unknown bugs remaining in the system.
>
> So here's the numbers of outstanding confirmed bugs from the various
> known bug lists.
>
> Date known bugs
> ---- ----------
> 27 Sep 19
> 28 Sep 16
> 1 Oct 21
> 23 Oct 25
> 1 Nov 27
> 21 Nov 38
> 27 Nov 42
> 2 Dec 37
> current 42 (list not yet published)
>
> We appear to be moving in the wrong direction.
> (That never happened at the bank.)
No, not at all. It is just that the team isn't as fast fixing bugs as they
are reported. However, the number of bug reports has actually decreased
when you look at the same period of time. For example, there had been about
20 reports in the first three weeks, but only another 20 in the past six
weeks. So effectively the rate of new bugs found has slowed down.
> current 42 (list not yet published)
Of course, you can't be sure that all those bugs hold up to an
investigation. Besides, some of the bugs in your list are scene/include
file only...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't know. It seems all hell broke loose when beta 8 was released. For
a while it looked like you might have to go back to beta 7.
Jim
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c0d1e6e@news.povray.org...
> In article <425### [at] econymdemoncouk> , Mike Williams
> <mik### [at] nospamplease> wrote:
>
> > When I did software testing for one of the UK high street banks we had a
> > theory about software bugs. We reckoned that the rate of fixing bugs in
> > a complex piece of software was approximately linear, but the rate of
> > finding new bugs decreases because there should be fewer bugs to find
> > (as long as the attempted bug fixes didn't introduce more new bugs as
> > side effects). By observing the way the number of known outstanding bugs
> > decreased over time, we considered it possible to estimate the probable
> > number of unknown bugs remaining in the system.
> >
> > So here's the numbers of outstanding confirmed bugs from the various
> > known bug lists.
> >
> > Date known bugs
> > ---- ----------
> > 27 Sep 19
> > 28 Sep 16
> > 1 Oct 21
> > 23 Oct 25
> > 1 Nov 27
> > 21 Nov 38
> > 27 Nov 42
> > 2 Dec 37
> > current 42 (list not yet published)
> >
> > We appear to be moving in the wrong direction.
> > (That never happened at the bank.)
>
> No, not at all. It is just that the team isn't as fast fixing bugs as
they
> are reported. However, the number of bug reports has actually decreased
> when you look at the same period of time. For example, there had been
about
> 20 reports in the first three weeks, but only another 20 in the past six
> weeks. So effectively the rate of new bugs found has slowed down.
>
> > current 42 (list not yet published)
>
> Of course, you can't be sure that all those bugs hold up to an
> investigation. Besides, some of the bugs in your list are scene/include
> file only...
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 6 Dec 2001 16:52:14 -0500, "Jim Kress"
<kre### [at] kressworkscom> wrote:
>I don't know. It seems all hell broke loose when beta 8 was released. For
>a while it looked like you might have to go back to beta 7.
>
I wish I could go back to beta 7. Unfortunately it has a timeout
and (short of setting my clock every tiem i want to use povray) I
can't run it anymore!
Hmmm. Any chance of talking the povteam into recompiling beta 7
with a timeout change? This could be used whilst they fix the
weirdness in beta 8.
Pete
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c10241e.10059241@localhost> , PeterC@nym.alias.net.almost
wrote:
> Hmmm. Any chance of talking the povteam into recompiling beta 7
> with a timeout change? This could be used whilst they fix the
> weirdness in beta 8.
The problems in beta 8 are fully predictable. They *only* involve
functions. In fact the same problems existed earlier but nobody would
notice because they did only happen with isosurfaces which would cause a
crash when printing max_gradient messages before. If you apply the
suggested workaround, or if you run only one scene and the restart POV-Ray
you can reliably work around the problem, which is sufficient to not go back
to the previous beta. Apart from that, it had other problems that have been
fixed in beta 8.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <425### [at] econymdemoncouk> , Mike Williams
<mik### [at] nospamplease> wrote:
> current 42 (list not yet published)
When will you post your most recent list?
BTW, the following bugs from your list (and others, not on your list and not
mentioned here) are fixed in the next beta so far:
Bug with intersection stack (with crash)(job000175)
http://news.povray.org/5f13rtc0v0rso4fk7lut5e0980qa9g756b@4ax.com
Alpha problems: text is not antialiased (job000187)
(black objects are not antialiased on Unix and Windows versions, alpha
is not correctly output on Mac)
http://news.povray.org/3bea5a84$1@news.povray.org
Focal blur aperture has no effect with camera types other than the
persective one (job000185)
http://news.povray.org/3bceb66d@news.povray.org
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Thorsten Froehlich who wrote:
>In article <425### [at] econymdemoncouk> , Mike Williams
><mik### [at] nospamplease> wrote:
>
>> current 42 (list not yet published)
>
>When will you post your most recent list?
I plan to post it about once a week, normally on Mondays.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
