 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
With POV-Ray 3.5 release there is considerable interest in source code
'hacking', many users fix bugs and add new features. Perhaps it would be
good to unite such efforts and create one version, which contains all
useful modifications. Best would be, if there is public (CVS) server,
which hosts source code and users can commit fixes and updates to it.
I don't know POV-Ray Team's position: whether there is intention to
create 'fixed' version of POV-Ray 3.5, which makes corrects known and
fixed bugs? If not (i.e. POV-Ray team will work only with version 4.0),
then this united POV-Ray could take this fixing over and be one source
for all patches.
ABX has made quite good work with his patches repository and
corrections, but with more wide developers base it could be even better?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ever seen Bugzilla for the Mozilla web browser? Mozilla is open source and
many people look at and modify the code to add features or fix bugs, and
they're all incorporated in the next version. Plus, nightly builds are that
update to any bugs fixed that day.
Check it out at http://www.mozilla.org/bugs/ . Could this be applied to
POV-Ray?
-DJ
"Vahur Krouverk" <vkr### [at] starman ee> wrote in message
news:3DA### [at] starmanee...
>
> With POV-Ray 3.5 release there is considerable interest in source code
> 'hacking', many users fix bugs and add new features. Perhaps it would be
> good to unite such efforts and create one version, which contains all
> useful modifications. Best would be, if there is public (CVS) server,
> which hosts source code and users can commit fixes and updates to it.
>
> I don't know POV-Ray Team's position: whether there is intention to
> create 'fixed' version of POV-Ray 3.5, which makes corrects known and
> fixed bugs? If not (i.e. POV-Ray team will work only with version 4.0),
> then this united POV-Ray could take this fixing over and be one source
> for all patches.
> ABX has made quite good work with his patches repository and
> corrections, but with more wide developers base it could be even better?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 10 Oct 2002 21:30:39 +0300, Vahur Krouverk <vkr### [at] starmanee>
wrote:
> With POV-Ray 3.5 release there is considerable interest in source code
> 'hacking', many users fix bugs and add new features. Perhaps it would be
> good to unite such efforts and create one version, which contains all
> useful modifications. Best would be, if there is public (CVS) server,
> which hosts source code and users can commit fixes and updates to it.
Somehow I thought the Team is against CVSed holding of POV-Ray sources in any
way but I agree it could be much better. I have never played with CVS but as
far as I see from other packages it is interesting.
> ABX has made quite good work with his patches repository
Oh, thanks :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vahur Krouverk wrote:
>
> With POV-Ray 3.5 release there is considerable interest in source code
> 'hacking', many users fix bugs and add new features. Perhaps it would be
> good to unite such efforts and create one version, which contains all
> useful modifications. Best would be, if there is public (CVS) server,
> which hosts source code and users can commit fixes and updates to it.
Hmm, for 4.0 this could be interesting but i don't know the official plans
in that concern.
For 3.5 patches i'm not sure if it would be of much help. Surely it would
help coders making small extensions or fixes available, but would it
improve the quality of the product? The quality of most megapov functions
was relatively low compared to those things now in 3.5 - and this although
megapov is relatively well tested and comes with a small documentation of
all features and sample scenes. Now if everyone can add any tiny
extension to a CVS tree without testing and writing any documentation this
could result in a lot of dead code not of much use for the POV-Ray
programmer, not to speak of the regular user who wants a ready-to-use
version.
I would probably start it the other way round. A 3.5 based megapov (as it
was already discussed quite frequently, it does not necessarily have to be
maintained by the same people as the old megapov. If you, Vahur, plan to
release a 3.5 based version of POVMan soon this could form the basis of a
new patch collection too) could be extended with a standardized system for
adding new functions. These could be suggested in the newsgroups and
would then be tested by those interested and if they conform the
requirements and are found useful they would be added to the next release
of the patch collection. A (public read only) CVS like system could be
useful for this but note the difference - it would not encourage a 'submit
and forget'-like manner of committing things.
What would definitely be a good idea is to maintain a list of officially
approved bug fixes. A regularly updated snapshot of the official source
with those modifications applied would be useful too. IIRC there are
already quite some fixes that were added to the official source code after
the first release of 3.5.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vahur Krouverk wrote:
>
> I don't know POV-Ray Team's position: whether there is intention to
> create 'fixed' version of POV-Ray 3.5, which makes corrects known and
> fixed bugs?
I really couldn't see why not. Many bugs are shallow bugs, and so
verifying that the 'fix' doesn't cause problems elsewhere isn't that
big an issue.
With several new sets of eyes looking at the source, the primary
benefit of publishing the source is in effect. The real test is to
hand the binaries to people who render obscenely complicated scenes and
see if they still render correctly (or even better).
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vahur Krouverk wrote:
>
> With POV-Ray 3.5 release there is considerable interest in source code
> 'hacking', many users fix bugs and add new features. Perhaps it would be
> good to unite such efforts and create one version, which contains all
> useful modifications.
Other projects have two versions: a stable and a developer version.
The first one is for people who actually want to use the program for
larger projects and therefore cannot afford to live with changing
syntax and unpredictable crashes. The second version is for people
(like me) who like to toy around with the newest, bleeding edge features
and don't care too much, if the program can't process a file that was
created for a two weeks old version of the program. This approach is
successfully applied to several larger projects including the Linux
kernel, so my suggestion is to copy it.
As it comes to POV-Ray, the "stable" version is probably the official
release. AFAIK the POV-Team includes known bug fixes in minor updates.
For the "developer" version -- I think -- we have to distinguish between
two cases: versions that are based on 3.5 ("3.5 MegaPov") and the
forthcoming 4.0, because the latter one is a rewrite from scratch.
So, from my point of view, we need three versions of POV-Ray.
> Best would be, if there is public (CVS) server,
> which hosts source code and users can commit fixes and updates to it.
I'm against a cvs server where anyone can submit patches. Usually
you have some kind of maintainer who decides which patches are
suited for this particular version. In the before-mentioned scenario,
a cvs server doesn't make much sense for the official version.
There are just too few realeases.
Furthermore, it's up to the POV-Team to decide whether 4.0 will
be developed using a public (read-only) cvs server. (I would really
love to see this happen and therefore hope that rumors about it are
true.)
Finally, for the 3.5 based MegaPov, a public cvs server would make
even more sense, because then developers could easily create their
patches for a common source base. Nevertheless I think that a
(group of) maintainer(s) is needed to ensure some kind of minimal
standard. If someone - as it has happend in the past - shows up
creating excellent patches I assume that such a person would get
write access to the cvs very quickly.
Just my Euro 0.02
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <i1tcqu4q7q0s51lajui5khjuu9j9gnijai@4ax.com>,
ABX <abx### [at] abxartpl> wrote:
> Somehow I thought the Team is against CVSed holding of POV-Ray sources in any
> way but I agree it could be much better. I have never played with CVS but as
> far as I see from other packages it is interesting.
From the POV-Team Status Report - September 1, 2000 in
povray.announce.frequently-asked-questions:
"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."
They don't use CVS, so that specifically wouldn't be possible unless
they decide to change their system, but I don't think you meant to
exclude all other code management software.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
DJ Wiza wrote:
> Ever seen Bugzilla for the Mozilla web browser? Mozilla is open source and
> many people look at and modify the code to add features or fix bugs, and
> they're all incorporated in the next version. Plus, nightly builds are that
> update to any bugs fixed that day.
>
Yes; I've seen, but pardon me, Perl based system????Yuck!
just kiddin', of course!
> Check it out at http://www.mozilla.org/bugs/ . Could this be applied to
> POV-Ray?
Perhaps, but I'm not quite sure, that there is need for such elaborated
system. Simple CVS should be sufficient, I guess. But I'm not against
better system either.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
> On Thu, 10 Oct 2002 21:30:39 +0300, Vahur Krouverk <vkr### [at] starmanee>
> wrote:
>
>>With POV-Ray 3.5 release there is considerable interest in source code
>>'hacking', many users fix bugs and add new features. Perhaps it would be
>>good to unite such efforts and create one version, which contains all
>>useful modifications. Best would be, if there is public (CVS) server,
>>which hosts source code and users can commit fixes and updates to it.
>
>
> Somehow I thought the Team is against CVSed holding of POV-Ray sources in any
> way but I agree it could be much better. I have never played with CVS but as
> far as I see from other packages it is interesting.
I use CVS (with ViewCVS, http://viewcvs.sourceforge.net/) at my work (3
differently located officies in 2 countries) and it seems to be quite
decent system for source code management (although it has some
deficiencies, that's why more elaborated systems, like BitKeeper or
Subversion are developed). AFAIK, CVS is used extensively in open source
community and this should be good enough argument :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Willhalm wrote:
>
> As it comes to POV-Ray, the "stable" version is probably the official
> release. AFAIK the POV-Team includes known bug fixes in minor updates.
I don't expect POV-Ray 4.0 anytime soon, perhaps in year 2004? If there
is really intention to make full rewrite, then I expect, that it takes
at least couple of years (unless some miracle happens and POV-Team
'conquers Mount Everest bare-foot' :-), so in the meantime POV-Ray
community is on its own and free to develop patches :-)
>
> I'm against a cvs server where anyone can submit patches. Usually
> you have some kind of maintainer who decides which patches are
> suited for this particular version.
Why? Sure, there should be some maintainer (or build-master or
whatever), who decides, which patches will go to release. Patch goes to
the CVS branch and buildmaster decides, what goes to the release and
will merge them with main branch (as it goes with CVS).
> In the before-mentioned scenario,
> a cvs server doesn't make much sense for the official version.
> There are just too few realeases.
As I said, I don't expect official new (4.0) version anytime soon
(although I'd be glad, if my expectations are incorrect!).
> Finally, for the 3.5 based MegaPov, a public cvs server would make
> even more sense, because then developers could easily create their
> patches for a common source base. Nevertheless I think that a
> (group of) maintainer(s) is needed to ensure some kind of minimal
> standard. If someone - as it has happend in the past - shows up
> creating excellent patches I assume that such a person would get
> write access to the cvs very quickly.
>
I tend to agree. If there is really doubt, that low-quality
pathes/bug-corrections will be submitted, then 'commit' access could be
limited to 'proven' persons by maintainer/buildmaster/whoever.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
