In article <3DA### [at] alphalinkcomau> , Edward Coffey 
<eco### [at] alphalinkcomau>  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] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3DA### [at] alphalinkcomau> , Edward Coffey
> <eco### [at] alphalinkcomau>  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

"Thorsten Froehlich" <tho### [at] trfde> 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

In article <3daf96aa@news.povray.org>,
 "Edward Coffey" <eco### [at] studentslatrobeeduau> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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

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

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3daf96aa@news.povray.org>,
>  "Edward Coffey" <eco### [at] studentslatrobeeduau> 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