|
![](/i/fill.gif) |
Christoph Hormann wrote:
> - the beta version Nicolas provided it not yet the final source release.
> It is *only* meant for testing the build system, not for doing
> anything else. We especially do not want unofficial versions based on
> this beta code to be created (which would of course be illegal but not
> everyone cares).
>
I do not intend to create unofficial binaries for distribution. I primarily
downloaded to test the build system because I felt that it was my duty
to do so. Then, I had a look at the docu and stumbled over the change log
at the same level as the html/ directory.
There, I saw that it did not mention several bugs which I reported, so I
felt that it was high time to have a look and tell people.
> - you have been visiting these newsgroups long enough to know the
> correct proceedings of a bug report. Still i can only find a single bug
> report from you in povray.bugreports.
>
If I post a patch against a bug in povray.programming and some member
of the POV team comments on it, then this must be enough. (Especially
if I am told that "it has been noted".)
If the POV team fails to include patches proposed this way, I do not
feel guilty for that.
Especially note that in most cases I am not providing a "bug report"
but actually a "bug fix". And I am just writing such one for the parametric
objet code (when reporting it, I was unable to fix the out-of-bounds
condition).
> - there has been a several month long beta phase for POV-Ray 3.6 and i
> don't remember any report from you in povray.beta-test. The only
> explanation i have for this is that you want to demonstrate the
> necessity to release the source code to get useful feedback...
>
Okay, so then please tell me how I could check if the "break;" in
the search loop was included from using the binary? How could I have done
so for the parametric object (the bug is still there but povray does no
longer crash becasue the overwritten memory is non-lethal)? How can
I tell from testing the binary that the radial pattern patch was included
(I do not have a test case for this since it is not really something which
shows up as image disortion but will make the function conform to the
allowed return value range stated in the code)?
Please tell me!
And trust me: I actually wanted to look at the code and see that everything
with the patches went fine. Because the other issues I had on my lists (see
my home page!) were actually fixed in the pre-release binaries:
There was the torus numerics patch where I provided a test scene:
Correctly fixed in prerelease so no reason for a bug report.
Then the various X11 fixes proposed by me: All were included in the
prerelease binaries, so no reason for a bug report, too.
Okay, and the other things I mentioned are no _real_ bugs:
The window close is a feature (as pointed out by N.C.), the rendering
status line is just eye candy [I actually thought this was mentioned by
somebody else in the beta testing stage] and the last one is a question
of me (eye-candy subject) and not a bug.
Wolfgang
Post a reply to this message
|
![](/i/fill.gif) |