![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 14 Oct 2002 21:26:43 +0200, Micha Riser <mri### [at] gmx net> wrote:
> > Seems like there is quite interest in this proposal. To be more concrete:
> > 1. Is out there anyone, who can provide (CVS?) server for unofficial
> > POV-Ray releases?
>
> I can set up CVS server on the povworld.org server. I am not an expert in
> CVS but I guess I could install it and the server has a more-or-less
> reliable connection to the net.
If there are no objections from the team around CVSed development of patched
3.5 and if you can setup some account for me, Micha, I think I can become
buildmaster for such server (unless You want to do it yourself). I can deliver
my PoPOV as initial version for such development. During further development
we can drop some *_PATCH definitions already included there. I have already
some ideas for directory structure for such multiplatform enviroment so
perhaps I could have best start for it. Can we use povray.unofficial.patches
as unofficial 'official' forum for this task then ?
ABX
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <9p5mqu46l513g9jchqkk0cdn3ni48rvkur@4ax.com>,
ABX <abx### [at] abx art pl> wrote:
> > Yes, but compilation with more effective compiler could be made by
> > someone else, maintainer would just be responsible for source code.
> What about cheap macintosh compilation ?
Apple provides a version of GCC and good IDE tools (ProjectBuilder and
InterfaceBuilder) for free. It can't compile the Mac version of POV
though, that requires CodeWarrior which is not cheap. It can compile the
command line version and there is a 3rd party Cocoa GUI out there,
though it is very incomplete.
I don't know if a ProjectBuilder project can be made with the current
Carbon GUI source...I doubt it could be done without a lot of work, but
I don't know a lot about Carbon.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
ABX wrote:
>
> [...]
>
> If there are no objections from the team around CVSed development of patched
> 3.5 and if you can setup some account for me, Micha, I think I can become
> buildmaster for such server (unless You want to do it yourself). I can deliver
> my PoPOV as initial version for such development. During further development
> we can drop some *_PATCH definitions already included there. I have already
> some ideas for directory structure for such multiplatform enviroment so
> perhaps I could have best start for it. Can we use povray.unofficial.patches
> as unofficial 'official' forum for this task then ?
If i may bring up some of my suggestions on that matter again.
Before getting into action setting up a repository of patches it would IMO
be good to develop some standards concerning the patches submitted to such
a collection. My main concerns in that direction were:
- a common documentation format.
- rules for the source code (like marking all changes with preprocessor
#ifdef's)
- rules for modification of existing patches (bugfixes, improvements).
Only by the original author or by everyone?
- organizing frequent compiled versions for the most important platforms.
Like Vahur pointed out these do not necessarily have to be made by the
maintainers of the patch collection.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3DA### [at] alphalink com au> , Edward Coffey
<eco### [at] alphalink com au> wrote:
>> You are kidding, right?
>
> Could you be more specific?
Well, I am just not sure it is a good idea at all. Or better, I should say
I was not sure if it is a good idea because of the possible flames and such
that would be the result. So I made a test (see the thread "Proposal for
4.0 core control" and my posts in there). Now I am not sure if there are
many people even familiar enough with the core code to participate in any
such discussion. Not really conclusive results at all :-(
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich wrote:
> In article <3DA### [at] alphalink com au> , Edward Coffey
> <eco### [at] alphalink com au> wrote:
>
>>> You are kidding, right?
>>
>> Could you be more specific?
>
> Well, I am just not sure it is a good idea at all. Or better, I should
> say I was not sure if it is a good idea because of the possible flames and
> such that would be the result.
Although you didn't get much output, there weren't any flames as ABX
correctly concluded.
> Now I am not sure if there are
> many people even familiar enough with the core code to participate in any
> such discussion.
Probably, but even if there're only a dozen, it might help. Other open
software programmers have chosen such an approach and are still doing so:
Linux or XFree to name just two not so small projects.
To create a newsgroup on news.povray.org for the delevopers sounds natural
to me. If there is too much background noise, you can still make it
moderated or even read-only for others. IMO you won't loose much (except
the reputation of a secret group doing strange things in the dark).
Just my 0.02 Euro
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Thorsten Froehlich" <tho### [at] trf de> wrote in message
news:3dac5b05$1@news.povray.org...
...
> Well, I am just not sure it is a good idea at all. Or better, I should
say
> I was not sure if it is a good idea because of the possible flames and
such
> that would be the result. So I made a test (see the thread "Proposal for
> 4.0 core control" and my posts in there). Now I am not sure if there are
> many people even familiar enough with the core code to participate in any
> such discussion. Not really conclusive results at all :-(
Forgive the essay:
Concerning flames, take the Linux Kernel Mailing List as an example, heated
discussions and unresolvable differences of opinion are not uncommon, but
outright flaming is. Overall I think the community here in these groups is
relatively close and supportive when compared with many other online fora,
and I don't see that opening dev discussion would be likely to disrupt that.
Since, according to Chris Huff, the team is still "hoping to use a much more
open development model for POV 4" I assume you mean it is not a good idea to
open dev discussions _at this time_ (it is hard to imagine open development
without open dev discussion at some point). I think by opening discussion
early (even if read-only for the general public at first) you head off a
great deal of the possible flamage by giving people a chance to understand
the motivations behind design decisions, rather than just saying "Here's
what we decided" and risking the response "That's stupid, why the hell did
you do that? Furthermore, you smell".
Certainly, your test does show that no-one was particularly familiar with
that aspect of the code, but I do not believe that familiarity with _every_
aspect of a program should be a prerequisite for participation in
development discussion. The lack of flaming in your test may also show that
when people in this community are not familiar with an aspect of the
program, they tend not to go spouting off about it, which is good: People
may get passionate and heated about aspects that fall within their sphere of
interest, but they know when to shut up too. Further, I would think that the
community of potential developers' lack of knowledge about the core code
would be good a reason to open dev discussion, not to keep it closed.
That no-one responded to your 'interesting' suggestions seems likely to be a
combination of the fact that not many people are particularly interested or
familiar with the area being discussed, and as Edmund Horner described, a
case of "the Emperor's new clothes": people saw one of the four primary
developers of 3.5 and thought 'well, he must know what he's talking about'.
Most people are going to treat your opinions with more weight than those of
most others.
In responding to Christoph Hormann you wrote:
> I don't want to have to answer the (as I expect it)
> resulting misunderstandings for the next half decade ... the problem is we
> can't keep the usual group of general users from reading such public
> discussions and getting completely misdirected :-( No matter how big the
> disclaimers ;-)
I really don't see this as a big problem, I think most people in the POV
community are smart enough to understand that a dev group would be just
that, a place for developers to come together and discuss ideas and
possibilities as well as concrete plans. If you want to make it absolutely
clear what is and is not planned you could publish a design document online,
complete with a list of all functionality planned for the initial release, a
class dictionary, class diagrams, possibilities for future expansion,
testing plans etc. then adding a formal POV-SDL specification, API
specifications and so on. I'm only part serious here, I do think a design
document would be a good idea, but I understand that most people find them
_extremely_ tedious.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3daf96aa@news.povray.org>,
"Edward Coffey" <eco### [at] students latrobe edu au> wrote:
> Since, according to Chris Huff, the team is still "hoping to use a much more
> open development model for POV 4"
Correction: that report was written by Chris Cason.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
ABX wrote:
>
> If there are no objections from the team around CVSed development of patched
> 3.5 and if you can setup some account for me, Micha, I think I can become
> buildmaster for such server (unless You want to do it yourself). I can deliver
> my PoPOV as initial version for such development.
Better would be to start from official version, then if POV-Team
releases new version, it will be easier merge those changes to patched
version. But this is probably different topic and should be discussed in
unofficial patches group.
> During further development
> we can drop some *_PATCH definitions already included there. I have already
> some ideas for directory structure for such multiplatform enviroment so
> perhaps I could have best start for it. Can we use povray.unofficial.patches
> as unofficial 'official' forum for this task then ?
I hope so.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christoph Hormann wrote:
> If i may bring up some of my suggestions on that matter again.
>
> Before getting into action setting up a repository of patches it would IMO
> be good to develop some standards concerning the patches submitted to such
> a collection.
[Snip]
Valid points, but I guess, that it will be better to discuss them in
unofficial patches group, where such things should belong. I should've
started it there, not here, so I f-up this post to there.
> - a common documentation format.
> - rules for the source code (like marking all changes with preprocessor
> #ifdef's)
> - rules for modification of existing patches (bugfixes, improvements).
> Only by the original author or by everyone?
> - organizing frequent compiled versions for the most important platforms.
> Like Vahur pointed out these do not necessarily have to be made by the
> maintainers of the patch collection.
- Perhaps some coding guidelines? I know, that this opens can of worms
and will be possible cause for endless discussions, but it would be
good to adopt some sensible coding standards. POV-Ray's code has evolved
long way and it could be seen from source code: different code layout,
different naming conventions used, some code uses tabs to ident code etc.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Christopher James Huff" <chr### [at] mac com> wrote in message
news:chr### [at] netplex aussie org...
> In article <3daf96aa@news.povray.org>,
> "Edward Coffey" <eco### [at] students latrobe edu au> wrote:
>
> > Since, according to Chris Huff, the team is still "hoping to use a much
more
> > open development model for POV 4"
>
> Correction: that report was written by Chris Cason.
When attributing to you I was referring more to the fact that the statement
was _still correct_, rather than the statement itself.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |