Sorry for re-posting this on the newsgroup but I did not get 
any response to it. 

What about applying this trivial patch? 
I think there is no need to continue the for() loop once 
we set found=true. 

/* NK phmap */
/* this function checks if 'object' is equal to 'parent' or is a child
 * of 'parent'
 */
static int IsObjectInCSG(OBJECT *Object, OBJECT *parent)
{
  OBJECT *Sib;
  int found;

  if (Object == parent) return true;

  found = false;
  if(parent->Type & IS_COMPOUND_OBJECT)
  {
    for (Sib = ((CSG *)parent)->Children; Sib != NULL; Sib = Sib->Sibling)
    {
      if(IsObjectInCSG(Object, Sib))
-        found = true;
+        {  found = true;  break;  }
    }
  }
  return found;
}

BTW, I would appreciate if you could establish ordinary version 
numbers like everybody else does. I mean, the file povuni_s.tgz 
on the FTP should be a symlink to povuni_s-3.5c.tgz or whatever. 

Making available incremental paches would be helpful, too because 
that makes it easier to keep a modified version around (though this 
is not necessary because I can make the patch myself). 

Wolfgang

Post a reply to this message

In article <3e46c362@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> What about applying this trivial patch?
> I think there is no need to continue the for() loop once
> we set found=true.

Yes, it has been noted.  It will be included sometime in the future.

> BTW, I would appreciate if you could establish ordinary version
> numbers like everybody else does. I mean, the file povuni_s.tgz
> on the FTP should be a symlink to povuni_s-3.5c.tgz or whatever.

The updates are platform specific.  Thus there is no new version, it is
still the same version of POV-Ray.

> Making available incremental paches would be helpful, too because
> that makes it easier to keep a modified version around (though this
> is not necessary because I can make the patch myself).

Due to the cross-platform nature of POV-Ray this is not feasible as it would
have to include platform specific as well as cross-platform changes.

    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

Thorsten Froehlich wrote:

> In article <3e46c362@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> BTW, I would appreciate if you could establish ordinary version
>> numbers like everybody else does. I mean, the file povuni_s.tgz
>> on the FTP should be a symlink to povuni_s-3.5c.tgz or whatever.
> 
> The updates are platform specific.  Thus there is no new version, it is
> still the same version of POV-Ray.

I'm sorry, but I have to agree with Wolfgang. A version number in the
file name would make sense. It's hard to guess, whether povuni_s.tgz
contains the sources for 3.1, 3.5, 3.5b, 3.6, or whatever. Of course,
if there is no difference in the source code between 3.5a and 3.5b,
it would be povuni_s-3.5.tgz. Different files should get different 
(recognizable) names. 

I am aware of the fact that there are still DOS users out there that
need a 8.3 filename. For the sake of the majority of the users however,
longer names would be preferable. If I remember correctly from the old
DOS days, ftp shortens the filename automatically. So, DOS users would 
not be harmed, but wouldn't benefit from version numbers.

Thomas

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3e46c362@news.povray.org> , Wolfgang Wieser
> <wwi### [at] gmxde> wrote:
>
>> What about applying this trivial patch?
>> I think there is no need to continue the for() loop once
>> we set found=true.
>
> Yes, it has been noted.  It will be included sometime in the future.

How about keeping a running snapshot of the latest work in progress on the
FTP, no guarantees that it will actually compile, use at your own folly etc
etc


--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

In article <3e48f6f1@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> I'm sorry, but I have to agree with Wolfgang. A version number in the
> file name would make sense. It's hard to guess, whether povuni_s.tgz
> contains the sources for 3.1, 3.5, 3.5b, 3.6, or whatever. Of course,
> if there is no difference in the source code between 3.5a and 3.5b,
> it would be povuni_s-3.5.tgz. Different files should get different
> (recognizable) names.

There are no changes to the code that are not Unix specific.  Labeling the
code as you suggest would only cause confusion.

    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 <3e492545$1@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:

> How about keeping a running snapshot of the latest work in progress on the
> FTP, no guarantees that it will actually compile, use at your own folly etc
> etc

No, that would expose changes that require platform specific changes to work
in the first place.  And we do not release such version for very good
reasons, which are obvious if you think about what would happen if we did
release such a source code version, and which in fact did happen in the
past...

    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

Thorsten Froehlich wrote:

> In article <3e48f6f1@news.povray.org> , Thomas Willhalm
> <tho### [at] uni-konstanzde>  wrote:
> 
>> I'm sorry, but I have to agree with Wolfgang. A version number in the
>> file name would make sense. It's hard to guess, whether povuni_s.tgz
>> contains the sources for 3.1, 3.5, 3.5b, 3.6, or whatever. Of course,
>> if there is no difference in the source code between 3.5a and 3.5b,
>> it would be povuni_s-3.5.tgz. Different files should get different
>> (recognizable) names.
> 
> There are no changes to the code that are not Unix specific.  Labeling the
> code as you suggest would only cause confusion.

Are you ignoring our point on purpose? We want _version_numbers_ in the
_filename_. The archive for 3.5 with source code for unix is called 
povuni_s.tgz, the archive for 3.1g with source code for unix is called 
povuni_s.tgz, and the archive for 3.0 with source code for unix is called 
povuni_s.tgz. If you don't believe me, check it yourself on ftp.povray.org.

I agree with you that one should use the same name if two archives contain 
the same code. However, I'm sure that this is not the case for the source
code of povray 3.0 and povray 3.5 (for any platform).

Thomas

Post a reply to this message

In article <3e4a0f09@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> Are you ignoring our point on purpose? We want _version_numbers_ in the
> _filename_. The archive for 3.5 with source code for unix is called
> povuni_s.tgz, the archive for 3.1g with source code for unix is called
> povuni_s.tgz, and the archive for 3.0 with source code for unix is called
> povuni_s.tgz. If you don't believe me, check it yourself on ftp.povray.org.

But what is the problem with that?  They are in two completely different
directories!!!  It doesn't cause any problems for the other platforms, and
didn't in the past ten years for Unix either, so why would it be a problem
for Unix archives today?  If someone does not even bother to check about the
directory they are in, well, sorry, a tiny bit of thinking is required when
downloading software.

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3e492545$1@news.povray.org> , "Rick [Kitty5]"
> <ric### [at] kitty5com> wrote:
> 
>> How about keeping a running snapshot of the latest work in progress on
>> the FTP, no guarantees that it will actually compile, use at your own
>> folly etc etc
> 
> No, that would expose changes that require platform specific changes to
> work
> in the first place.  And we do not release such version for very good
> reasons, which are obvious if you think about what would happen if we did
> release such a source code version, and which in fact did happen in the
> past...

Seems like I'm too stupid to see what's obvious to you. The following
open source projects have public developer version:

OpenOffice
http://www.openoffice.org/dev_docs/source/643c/source.html#getsource
GCC        http://gcc.gnu.org/cvs.html
KDE        http://developer.kde.org/build/compile_cvs.html
Gnome      http://developer.gnome.org/tools/cvs.html
FreeBSD    http://www.freebsd.org/support.html#cvs
Linux      http://www.kernel.org/pub/linux/kernel/v2.5/
Xfree      http://www.xfree86.org/cvs/
Mozilla    http://www.mozilla.org/cvs.html
Apache     http://www.apache.org/foundation/cvs.html
Darwin     http://developer.apple.com/darwin/tools/cvs/
Blender    http://projects.blender.org/cvsx/?group_id=9
Wings3d    http://sourceforge.net/cvs/?group_id=33028

Why does it work for them but not for you?

Thomas

Post a reply to this message

In article <3e4a1b89@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> Why does it work for them but not for you?

Because fools (aka people who don't read any manuals, readmes, etc) start
patching those versions and the distribute them.  Or people compile them and
never update and then come back three years later complaining that bugs
supposedly haven't been fixed.  Has happened in the past...

    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

> But what is the problem with that?  They are in two completely different
> directories!!!  It doesn't cause any problems for the other platforms, and
> didn't in the past ten years for Unix either, so why would it be a problem
> for Unix archives today?  If someone does not even bother to check about the
> directory they are in, well, sorry, a tiny bit of thinking is required when
> downloading software.

	Here I agree with Thomas.

	The point is that it's annoying to rename a file you want to
download when its content (the tar archive) is clearly containing the
version information. Untaring a povuni_s.tgz file can led to either
povray-3.50c/, povray31/ or povray30/ folders. A filename, as a variable of
function name, should be something explicit enough as to avoid
confusion. Futhermore it's been a long time that *nix systems are
not limited to 8 caracters in filenames.
	If you keep several versions of the povray tar file, you have
to rename it yourself, while it _can_ be done already for you (exactly
as a ./configure script is made for simplicity).

	I definitely vote (can I ?) for renaming:

povuni_s.tgz to povray-3.50c.tar.gz for the current version.

	It's obvious the source are therein. For binaries there
are all those .rpm or .deb extension. For seperated docs, a -doc
suffix can be added. The configuration scripts I recently proposed
are available as a povray-3.50c-config.tar.gz file.

	It's nothing to do for the POV-Team, but it clarifies things
a lot for all thousands -- billions ?  :o) of unix users.

	- NC

Post a reply to this message

Thomas Willhalm wrote:
> Thorsten Froehlich wrote:
>> In article <3e48f6f1@news.povray.org> , Thomas Willhalm
>> <tho### [at] uni-konstanzde>  wrote:
>> 
>> There are no changes to the code that are not Unix specific.  Labeling
>> the code as you suggest would only cause confusion.
> 
> Are you ignoring our point on purpose? We want _version_numbers_ in the
> _filename_. The archive for 3.5 with source code for unix is called
> povuni_s.tgz, the archive for 3.1g with source code for unix is called
> povuni_s.tgz, and the archive for 3.0 with source code for unix is called
> povuni_s.tgz. If you don't believe me, check it yourself on
> ftp.povray.org.
> 
Well, that was not what I wanted to point out. Becuase the directory 
these files are in identifies them. However, it is generally a good 
idea to increase subversion or patchlevel numbers each time the 
content of a file changes. Relaying on the modification time stamp 
is a bit problematic and forces you to know which _date_ you last 
updated. 

I'm quite sure that NOT using such version numbers causes more confusion 
than using them (at least as symlink). 
OTOH I was again not aware that you actually have different source code 
packages for different platforms (which is quite uncommon to me). 

So, do what you think is best :)

However, if bandwidth is a problem for POVRay people, supplying 
pachtes between different UNIX source code versions could help. 
(Because I can either dl a patch at 4.5 kb/sec or dl complete POVRay 
on the university account and create my own patch there...)
This, however, would require subversion/patchlevel numbers. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3e4a1b89@news.povray.org> , Thomas Willhalm
> <tho### [at] uni-konstanzde>  wrote:
>
>> Why does it work for them but not for you?
>
> Because fools (aka people who don't read any manuals, readmes, etc)
> start patching those versions and the distribute them.  Or people
> compile them and never update and then come back three years later
> complaining that bugs supposedly haven't been fixed.  Has happened in
> the past...

So the whole idea is junk just because you have a problem with a few idiots.
Would the benefits of open development not outweigh the problems.


--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3e4a1b89@news.povray.org> , Thomas Willhalm
> <tho### [at] uni-konstanzde>  wrote:
> 
>> Why does it work for them but not for you?
> 
> Because fools (aka people who don't read any manuals, readmes, etc) start
> patching those versions and the distribute them.  Or people compile them
> and never update and then come back three years later complaining that
> bugs
> supposedly haven't been fixed.  Has happened in the past...

Then I suggest that you stop completly distributing source code and include 
an expiration date in every binary. Otherwise you can't make sure that 
similar things will happen again.

Again: What makes povray so different from all the projects I mentioned?

Thomas

Post a reply to this message

In article <3e4b6184@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> Then I suggest that you stop completly distributing source code and include
> an expiration date in every binary. Otherwise you can't make sure that
> similar things will happen again.
>
> Again: What makes povray so different from all the projects I mentioned?

It is a program for users with a long history of stability.  None of the
other projects you mentioned has _all_ these attributes:

1. a long history
2. a stable source base
3. did not fork wildly or was abandoned for an extended period of time
4. cross-platform compatibility
5. all operating system support
6. user, rather than computer scientist centric
7. does require substancial knowledge about topic to make modifications
8. is more than a "I don't like M$ project"

The projects you mentioned don't have:

OpenOffice 1,2,7,8
GCC        3,6
KDE        3,5,7,8
Gnome      3,5,7,8
FreeBSD    3,5,6
Linux      3,5,6,8
Xfree      3,6,7
Mozilla    1,2,7,8
Apache     5,6,7
Darwin     1,3,4,6
Blender    1,2,5
Wings3d    1,2,5

    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

"Rick [Kitty5]" wrote:
> 
> [...]
> 
> So the whole idea is junk just because you have a problem with a few idiots.
> Would the benefits of open development not outweigh the problems.

Just to make sure this does not get lost - nothing prevents anyone from
starting an 'open development project' based on the official sources
(within the restrictions of povlegal of course).

But you surely have noticed that none of the unofficial versions of
POV-Ray that exist is developed with free access to the working branch of
the code.

But getting back to the origin of this thread - somewhat more frequent
version updates are surely something a lot of people would appreciate.  It
is something Megapov tries to cover (at the cost of other things in which
official POV-Ray is superior to Megapov) although i admit at the moment
Megapov is not updated very often either.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3E4B7491.5FBB5892@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> But getting back to the origin of this thread - somewhat more frequent
> version updates are surely something a lot of people would appreciate.  It
> is something Megapov tries to cover (at the cost of other things in which
> official POV-Ray is superior to Megapov) although i admit at the moment
> Megapov is not updated very often either.

The reason is simply that many changes require a lot of testing.  All
projects with commitment to stability have few releases with the consequence
that users update infrequently...

    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

Thorsten Froehlich wrote:
> In article <3e4b6184@news.povray.org> , Thomas Willhalm
> <tho### [at] uni-konstanzde>  wrote:
>> Again: What makes povray so different from all the projects I mentioned?
> 
> It is a program for users with a long history of stability.  None of the
> other projects you mentioned has _all_ these attributes:
> 
Sorry...
I did not want to join this thread again but it seems the readers 
get to know your personal motivation for some of your optinions. 

Hint for the readers: Especially note point 8 in the list below and 
combine it with: 

(Thorsten Froehlich, Sunday 02 February 2003 13:56:19)
> The GPL comes with a
> political message that is not acceptable to all team members. 
> It certainly isn't acceptable to me.

...and...

(Thorsten Froehlich, Thursday 06 February 2003 20:15:54): 
> The whole idea of the FSF and thus the GPL is to turn software development
> and ownership of software into some kind of communism.  It seeks to strip
> an elite group (programmers) from the right to make money from their
> creative work and sole right to their work.  Instead the masses of
> uneducated wannabe programmers are allowed to screw up the programs.

[You probably noticed yourself that there are some right aspects but 
the way you put it here is more or less bullshit. No need for flame war.]

Let's read on: 

> 1. a long history
> 2. a stable source base
> 3. did not fork wildly or was abandoned for an extended period of time
> 4. cross-platform compatibility
> 5. all operating system support
"all OS support" wow...

> 6. user, rather than computer scientist centric
That depends on how you see it. 

> 7. does require substancial knowledge about topic to make modifications
> 8. is more than a "I don't like M$ project"
> 
> The projects you mentioned don't have:
> 
> OpenOffice 1,2,7,8
OpenOffice used to be 8. But no longer IMO. 

> GCC        3,6
> KDE        3,5,7,8
> Gnome      3,5,7,8
> FreeBSD    3,5,6
> Linux      3,5,6,8
>
Note: Linux has 8 but FreeBSD not. Hm. 
So, running FreeBSD is not 8 but running KDE on FreeBSD _is_ 8...

> Xfree      3,6,7
7: Patching POVRay is easier than patching XFree86, at least for me. 
6: Hm?

> Mozilla    1,2,7,8
I object to 8 here. You certainly know what IE is?!

> Apache     5,6,7
> Darwin     1,3,4,6
>
Note: Darwin does not have 8 but 6 ?!

> Blender    1,2,5
> Wings3d    1,2,5
> 

Wolfgang

Post a reply to this message

In article <3e4c0b9a@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> It is a program for users with a long history of stability.  None of the
>> other projects you mentioned has _all_ these attributes:
>>
> Sorry...
> I did not want to join this thread again but it seems the readers
> get to know your personal motivation for some of your optinions.

Well, I had at more than one occasion to deal with some of the projects you
mentioned.  And despite sufficient knowledge and a plain and normal system,
I have always had problems even when working on what the authors of that
software consider a standard configuration.  And I have looked at plenty of
Linux (kernel) code, which makes me seriously worry if the people who work
on it have any idea about quality at all.  Considering it is much younger
than the POV-Ray code base, it is a total complete mess of hacks over hacks
and completely unplanned software design.  Definitely not something I would
install an a production system.  I rather install an M$ system because there
I at least don't have to see how badly engineered the code is; and it can't
be worse than Linux code anyway...

> (Thorsten Froehlich, Thursday 06 February 2003 20:15:54):
>> The whole idea of the FSF and thus the GPL is to turn software development
>> and ownership of software into some kind of communism.  It seeks to strip
>> an elite group (programmers) from the right to make money from their
>> creative work and sole right to their work.  Instead the masses of
>> uneducated wannabe programmers are allowed to screw up the programs.
>
> [You probably noticed yourself that there are some right aspects but
> the way you put it here is more or less bullshit. No need for flame war.]

Oh, I indeed know that the way I put it is rather provocative... ;-)

>> FreeBSD    3,5,6
>> Linux      3,5,6,8
>>
> Note: Linux has 8 but FreeBSD not. Hm.
> So, running FreeBSD is not 8 but running KDE on FreeBSD _is_ 8...

Yes, because the FreeBSD license would allow even M$ to use code from it.

>> Xfree      3,6,7
> 7: Patching POVRay is easier than patching XFree86, at least for me.
> 6: Hm?

The 6 is there because the driver model is so unstructured.  It improved in
4.x of course...

>> Darwin     1,3,4,6
>>
> Note: Darwin does not have 8 but 6 ?!

No use can possibly install it on a Mac, really!  And large parts are forked
from FreeBSD.  the license allows hardly anybody to fork from this codebase,
so it isn't competitive, but just marketing.  Hence no 8.

In any case, the main point of the list is to show that all these projects
are very different from POV-Ray.

    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 rather install an M$ system because there
> I at least don't have to see how badly engineered the code is; and it can't
> be worse than Linux code anyway...

	:-) :-) :-) :-)

	Thorsten, it's not because you don't see what's in a black box
that you should trust it...
	Of course you were kidding (please tell me you were).

	Do you know that, since the open-source community contributed
so terrible code, Microsoft is re-using most of it by rewritting all
things in their graphically-based-windows-which-is-not-good-for-an-OS ?
That means introducing even more bugs and/or security holes ?

	I'm not against microsoft windows at all. I like it. But I use
it on my PC at home mostly to watch DVDs. I won't use it for my work
(and unfortunately I use POV only at work). But who cares.

	- NC

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3e4c0b9a@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
> wrote:
> 
> 
>>>It is a program for users with a long history of stability.  None of the
>>>other projects you mentioned has _all_ these attributes:
>>>
>>
>>Sorry...
>>I did not want to join this thread again but it seems the readers
>>get to know your personal motivation for some of your optinions.
> 
> 
> Well, I had at more than one occasion to deal with some of the projects you
> mentioned.  And despite sufficient knowledge and a plain and normal system,
> I have always had problems even when working on what the authors of that
> software consider a standard configuration.  And I have looked at plenty of
> Linux (kernel) code, which makes me seriously worry if the people who work
> on it have any idea about quality at all.  Considering it is much younger
> than the POV-Ray code base, it is a total complete mess of hacks over hacks
> and completely unplanned software design.  Definitely not something I would
> install an a production system.  I rather install an M$ system because there
> I at least don't have to see how badly engineered the code is; and it can't
> be worse than Linux code anyway...
> 
> 
>>(Thorsten Froehlich, Thursday 06 February 2003 20:15:54):
>>
>>>The whole idea of the FSF and thus the GPL is to turn software development
>>>and ownership of software into some kind of communism.  It seeks to strip
>>>an elite group (programmers) from the right to make money from their
>>>creative work and sole right to their work.  Instead the masses of
>>>uneducated wannabe programmers are allowed to screw up the programs.
>>
>>[You probably noticed yourself that there are some right aspects but
>>the way you put it here is more or less bullshit. No need for flame war.]
> 
> 
> Oh, I indeed know that the way I put it is rather provocative... ;-)

Given the recent conversations in this thread, and the views that you 
have made abundantly clear, could you give us an update on the following 
statement from the POV-Team Status Report, September 1, 2000:

 > Second, we are also hoping to use a much more open development model
 > for POV 4, with public read access to our source-revision tree.
 > System analysis, design, and implementation of POV 4 will be a very
 > large task, and this is one way we hope to speed it up.  This open
 > development model would also hopefully provide development releases
 > (snapshots) more quickly to the power-user community, similar to what
 > MegaPov offers now.

Perhaps an updated status report could save you some of the time you 
spend responding to speculation in this group.

Post a reply to this message

Edward Coffey wrote:

> Perhaps an updated status report...

Update: They are still squashing minor bugs in 3.5.

-- 
Ken Tyler

Post a reply to this message

Ken wrote:
> 
> Edward Coffey wrote:
> 
> 
>>Perhaps an updated status report...
> 
> 
> Update: They are still squashing minor bugs in 3.5.
> 

Ok, I was wrong. An update won't stop speculation.

Post a reply to this message

Edward Coffey wrote:
> 
> Given the recent conversations in this thread, and the views that you
> have made abundantly clear, could you give us an update on the following
> statement from the POV-Team Status Report, September 1, 2000:
> 
>  > Second, we are also hoping to use a much more open development model
>  > for POV 4, with public read access to our source-revision tree.
>  > System analysis, design, and implementation of POV 4 will be a very
>  > large task, and this is one way we hope to speed it up.  This open
>  > development model would also hopefully provide development releases
>  > (snapshots) more quickly to the power-user community, similar to what
>  > MegaPov offers now.
> 
> Perhaps an updated status report could save you some of the time you
> spend responding to speculation in this group.

Thank you Edward! This is indeed the point. Thorsten, could you please
approve, decline, or update this statement? What I understand from your
answers in this and similar threads:
- You don't want public read access to the source-revision tree.
- You don't want to discuss and make design decisions in a public forum.
- You don't think that an open development model speeds up the development.
- You don't want to release development releases (snapshots).
Since the statement can be found on
http://mac.povray.org/support/status.html
and your are listed in the POV-Team as Mac developer, this is rather
contradictive. Either your personal opinion is in conflict with the
majority of the POV-Team or the statemen is obsolete and should be removed 
from official public web pages.

Thomas

Post a reply to this message

> Thank you Edward! This is indeed the point. Thorsten, could you please
> approve, decline, or update this statement?

The 11/2000 statement part about the development model is, and always was,
for 4.0 only.

> What I understand from your answers in this and similar threads:
> - You don't want public read access to the source-revision tree.

Not for 3.5, yes.  This in line with what the team always said.  That said,
in fact several (the whole TAG, the MegaPOV developers and a few other)
non-team members do have read access to the source code.

> - You don't want to discuss and make design decisions in a public forum.

Honestly, yes, for any version.  But that is my personal opinion. Design by
majority simply does not work.

> - You don't think that an open development model speeds up the
development.

From my experinece with the 3.1 patches and the work required to make them
useable in 3.5, yes.  It is nothing against the patch authors personally,
but unfortunately the quality of many (not all!) patches was significantly
lower than anybody in the team expected.  So what worries me is that end the
end team mebers would have to go any fix all the code that is submitted
because nobody else does it... :-(

> - You don't want to release development releases (snapshots).

Not for 3.5, yes. This in line with what the team always said.

> Either your personal opinion is in conflict with the
> majority of the POV-Team or the statement is obsolete and should be
removed
> from official public web pages.

Neither what I say contradicts anything previously said. You are seeing
contradictions where there are none.

    Thorsten

Post a reply to this message

On Fri, 14 Feb 2003 10:17:26 +0100, Thomas Willhalm
<tho### [at] uni-konstanzde> wrote:
> Thank you Edward! This is indeed the point. Thorsten, could you please
> approve, decline, or update this statement? What I understand from your
> answers in this and similar threads:
> - You don't want public read access to the source-revision tree.
> - You don't want to discuss and make design decisions in a public forum.
> - You don't think that an open development model speeds up the development.
> - You don't want to release development releases (snapshots).
> Since the statement can be found on
> http://mac.povray.org/support/status.html
> and your are listed in the POV-Team as Mac developer, this is rather
> contradictive. Either your personal opinion is in conflict with the
> majority of the POV-Team or the statemen is obsolete and should be removed 
> from official public web pages.

Are you saying like:

( Thorsten in POV-Team ) => ( Thorsten opinion == POV-Team opinion )

which is simply false becouse group decisions usually not require unified
voice of all members.

IMO this disccusion follows wrong way. It seems that only argument to make
open development for POV 4.0 is that Thorsten is in contradiction to the rest
of the POV-Team. I do not see any argument like:
- look at this project - it moved to Open Source and community, stability and
quality increased
- look at my skills (except Vadim :) )
- look at this part of code - it is a bad design it can be done in C++ as ...
- look at this dead raytracing project - it has some good ideas in C++

Instead of valid arguments I see something like "You said ... and ... and ...
so you should not be a designer". I really want open developent of POV 4.0 and
I already started to increase my own skills and hardware as preparation to
this stage. But after such discussions I understand opportunities in the Team
- prespectives of having open development can be lost becouse time will be
wasted for discussions how zip is named. In open development we will have to
cooperate. As long as repository is not open please respect Team decisions and
rather concern more on arguments why open development can make POV better
(with examples) either becouse of your personal experience and becouse of
general advantages.

ABX

Post a reply to this message

ABX wrote:

> On Fri, 14 Feb 2003 10:17:26 +0100, Thomas Willhalm
> <tho### [at] uni-konstanzde> wrote:
>> Thank you Edward! This is indeed the point. Thorsten, could you please
>> approve, decline, or update this statement? What I understand from your
>> answers in this and similar threads:
>> - You don't want public read access to the source-revision tree.
>> - You don't want to discuss and make design decisions in a public forum.
>> - You don't think that an open development model speeds up the
>> development. - You don't want to release development releases
>> (snapshots). Since the statement can be found on
>> http://mac.povray.org/support/status.html
>> and your are listed in the POV-Team as Mac developer, this is rather
>> contradictive. Either your personal opinion is in conflict with the
>> majority of the POV-Team or the statemen is obsolete and should be
>> removed from official public web pages.
> 
> Are you saying like:
> 
> ( Thorsten in POV-Team ) => ( Thorsten opinion == POV-Team opinion )

No, I never wanted to say that. That's why I wrote:
"Either your personal opinion is in conflict with the
 majority of the POV-Team..."

I am aware of the fact that Thorsten and not the POV-Team is answering,
and Thorsten answered accordingly by pointing out where his opinion
differs from other POV-Team members.

> IMO this disccusion follows wrong way. It seems that only argument to make
> open development for POV 4.0 is that Thorsten is in contradiction to the
> rest of the POV-Team. 

Sorry, I don't think I understand this sentence. Are you saying that
in my opinion POV 4.0 should use an open model for development, because
Thorsten disagrees with some other team member? I never wanted to say
something even similar to that. 

I wanted to find out whether what Thorsten wrote in this and other 
threads more or less represents the opinion of the other POV-Team members 
and whether the cited statement still holds. Both points were answered
by Thorstens response, so I'm happy now.

> I do not see any argument like:
> - look at this project - it moved to Open Source and community, stability
> and quality increased

Well, my list of open source projects that are in my opinion valuable
comes close to this.

> - look at this dead raytracing project - it has some good ideas in C++

I did something similar: Look at these papers about fur, they look 
interesting, here is my current implementation. Unfortunately, nobody 
else was interested.

> Instead of valid arguments I see something like "You said ... and ... and
> ... so you should not be a designer". 

I never said that Thorsten shouldn't be a designer or anything similar
to that. I never questioned Thorsten's position in the POV-Team
and if you got this impression (e.g. because of my bad English), I would
like to correct this here.

As I already said, my questions are answered and in my opinion we can
move on now (although I really wished the POV 4.0 age would start
soon and rumors about it could stop).

Happy tracing
Thomas

Post a reply to this message

On Fri, 14 Feb 2003 13:18:50 +0100, Thomas Willhalm
<tho### [at] uni-konstanzde> wrote:
> No, I never wanted to say that. That's why I wrote:
> "Either your personal opinion is in conflict with the
> majority of the POV-Team..."
>
> I am aware of the fact that Thorsten and not the POV-Team is answering,
> and Thorsten answered accordingly by pointing out where his opinion
> differs from other POV-Team members.

How it can make the progress better nowadays? Does Thorsten's explanation
changed meaning of http://mac.povray.org/support/status.html ? If not the
whole discussion is a waste of time when 3.51 is coming.

> > IMO this disccusion follows wrong way. It seems that only argument to make
> > open development for POV 4.0 is that Thorsten is in contradiction to the
> > rest of the POV-Team. 
>
> Sorry, I don't think I understand this sentence. Are you saying that
> in my opinion ...

That's the problem, please not make such discussions "you said ... that I said
... but I said ...". Please find "you" in quoted text. Then please find text
"this discussion" :-)

> > I do not see any argument like:
> > - look at this project - it moved to Open Source and community, stability
> > and quality increased
>
> Well, my list of open source projects that are in my opinion valuable
> comes close to this.

Show us the list of those projects. Show us the list of designers, maintainers
and fixed / not fixed bugs there.

> > - look at this dead raytracing project - it has some good ideas in C++
>
> I did something similar: Look at these papers about fur, they look 
> interesting, here is my current implementation. Unfortunately, nobody 
> else was interested.

I do not remember this. Which post of
http://news.povray.org/search/advanced/?s=%22Thomas+Willhalm%22&&a=1
contain link to your papers ?

> As I already said, my questions are answered and in my opinion we can
> move on now (although I really wished the POV 4.0 age would start
> soon and rumors about it could stop).

I wish it too. If it only could be done the way that MegaPOV is taking role of
bugfixer so Team can concern on making rules for 4.0...

ABX

Post a reply to this message

In article <3e4ccfe5@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

BTW, something is wrong with your computer's time setting.  It would be nice
if you would fix it.

    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

Thorsten Froehlich wrote:
 >>Thank you Edward! This is indeed the point. Thorsten, could you please
 >>approve, decline, or update this statement?
 >
 >
 > The 11/2000 statement part about the development model is, and always 
was,
 > for 4.0 only.
 >
 >
 >>What I understand from your answers in this and similar threads:
 >>- You don't want public read access to the source-revision tree.
 >
 >
 > Not for 3.5, yes.  This in line with what the team always said.  That 
said,
 > in fact several (the whole TAG, the MegaPOV developers and a few other)
 > non-team members do have read access to the source code

Therein lay my confusion, I didn't realise that you had been referring
only to 3.5 development. Thanks for the clarification.

 >>- You don't want to discuss and make design decisions in a public forum.
 >
 >
 > Honestly, yes, for any version.  But that is my personal opinion. 
Design by
 > majority simply does not work.

Certainly not. But discussing and making design decisions in a public
forum does allow interested parties to make suggestions, none of which
you need to follow, but some of which may be useful. It also allows
people to better understand motivations, philosophy and overall
direction of the project, so they ask fewer dumb "Why don't you...?"
questions, they make fewer uninformed, poor quality suggestions, and
more high quality, useful ones. So, I hope 4.0 does take this path, but 
I agree that design by majority is a bad idea.

 >>- You don't think that an open development model speeds up the
 >
 > development.
 >
 > From my experinece with the 3.1 patches and the work required to make 
them
 > useable in 3.5, yes.  It is nothing against the patch authors personally,
 > but unfortunately the quality of many (not all!) patches was 
significantly
 > lower than anybody in the team expected.  So what worries me is that 
end the
 > end team mebers would have to go any fix all the code that is submitted
 > because nobody else does it... :-(

Nope, you just say "We'll look at that patch just as soon as your
implementation doesn't suck." With the possibility that they can have
their feature included if they clean it up a little, I suspect people
are likely to do so. You have the added benefit that because there are
more people around with a better understanding of the standards required
etc. they, rather than you, can help people clean up their patches.

 >>- You don't want to release development releases (snapshots).
 >
 >
 > Not for 3.5, yes. This in line with what the team always said.
 >
 >
 >>Either your personal opinion is in conflict with the
 >>majority of the POV-Team or the statement is obsolete and should be
 >
 > removed
 >
 >>from official public web pages.
 >
 >
 > Neither what I say contradicts anything previously said. You are seeing
 > contradictions where there are none.

Quite so.

Post a reply to this message

On 7/31/19 6:20 AM, masonlava wrote:

POV-Ray does not directly support HP printers, only Centronics.  There
used to be a patch that added PCL-2 but it was never updated to color PCL-5.


-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message