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

>> Why?  The policy to not make development source code accessible has a good
>> reason, because it simply did not work in the past.  Considering that back
>> in that "past" far fewer users with a lot more technical clue has access
>> to online resources, the internet of today does only make matters worse.
>>
> The proper reaction IMO is to find those people which do have a clue.

You really think we have the time to manage read access rights for many
developers?  It is really hard to tell somebody who just wants to lurk at
the code to someone who is going to contribute something.  So the
alternative would be to make the source code readable for everybody, which
in turn would result in people make distributions based on that code, which
is something they absolutely should not make.

>> And periodically looking at various "open source" development projects
<snip>
> [I am skipping this paragraph in an attempt to not feed the trolls.]

Take a look at the Debian povray package.  How they fixed the code to
compile on 64 bit platforms says a whole lot about the quality of their
"fix".  Especially as a correct solution had been available on this server
for a very long time before they "fixed" it.

>> My personal opinion is that no future patches' source code from MegaPOV
>> should be added to an official POV-Ray at all.  This is from the very bad
>> experience with patch quality that caused massive problems getting a
>> timely release of POV-Ray 3.5, and even in 3.6 not all of the flaws in
>> some patches have been corrected.
>>
> I do not completely understand that. In order to advanve/innovate one
> needs to add code to existing code, hence "patch" it. If you do not
> patch code, you stop development.

If the next release, which will be 4.0 and is a rewrite, what point would
there be in adding new minor patches to the official 3.x code base?

> So what is the alternative?
> Direct implementation by a POV team member (with inspiration from
> the patch code)?
>
> In this case we definitely need megapov as a patch playground because
> the above tends to take quite long...

Indeed, it takes so long because quality software development takes long.
That way we don't need to release hot fixes every other day like many other
companies and projects do.  And users don't have to hunt down the latest and
greatest version every other day either.

> Maybe we are using slightly differrent meanings for "patch".

Nope.

> This is clear (although I think that "just converting" the parametric
> object will not be that easy...)

As I said, "most" objects.  And the parametric object is one with the most
bugs still in it.

> As you are talking about version 4.0, I think it should not only be
> a re-write but a re-design

That is obvious!

>> And you can be sure the community as well as the POV-Team will
>> greatly appreciate bug fix contributions.
>>
> (And any bug fix writer will appeciate access to up-to-date source code...)

Why?  It is much easier to track down a bug if the source code does not
change while you are tracking it down, so it is irrelevant if you have the
most recent source code and can't update it or you have the release source
code of the last official version and can't update it until you have found
the bug.

>> I strongly disagree.  All "those people who want to work" usually do only
>> want to add features.  They have no desire to go through the very time
>> consuming, boring and frequently frustrating process of fixing bugs.  So,
>> when pushing for a quick including of a patch into the official POV-Ray,
>> these people also want to leave at least some of the work of fixing the
>> bugs to the POV-Team.
>>
> (1) One does not need to integrate patches quickly into povray.
>     But one could at least make it easier for people to write their
>     patches.

It is very easy to write patches that add new objects and patterns.  You
don't need any non-final source code to do that.  As far as other features
are concerned, those should really not be added unless they add something
truly useful to most users, the code outside objects and textures has enough
problems already.

> If one threatens to de-integrate the patch, there will probably be
> somebody who finds it useful and takes over the responsivbility.
> If tere is not, there seems to be no interest at all and one can live
> without that functionality.
> I don't think this is the best solution but a fallback...

You miss an important point: Also no developer is interested in a particular
patch does not say anything about no user being interested in a patch.  You
make the typical mistake all these "open source" proponents do, in assuming
that everybody who uses a program is also able to fix it.  That is of course
nonsense.  Even the average advanced user of POV-Ray does not know
programming...

> It's just that I learned to never fix bugs in old versions. I tracked
> down other bugs for other projects and the correct behaviour always was
> use the current development code and not a one-year-old code base.

I think you are mistaken.  The correct behavior always is to use the version
they make available.  In many of those projects individual developers in
turn keep large changes private and only contribute them when they are
"ready".  Thus, it just moves the problem around, but does not help to solve
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