Alexandre DENIS wrote:
> Specialist in parallel programming would have been a great addition in the
> POV-Team, but the current strategy let me believe that external
> contributors are not welcome.

External contributors are welcome, despite appearance.

The large structural changes that the source code went through and our
attempts to get it stable were in part the reason we didn't have it
available. Though really that's not much of an excuse and I accept that we
should have put it out there earlier.

-- Chris

Post a reply to this message

Jim Henderson  wrote in message <48800f62$1@news.povray.org>:
> I disagree.  If an author wants to limit distribution of their software, 
> that's *absolutely* their right.

That is their right, of course, but the software is no longer libre.

Post a reply to this message

Nicolas George wrote:
> Do you not agree that, in order to attract contributors, you need to make
> them feel welcome?

Please note that Thorsten speaks for himself when posting here (unless he
explicitly says otherwise). As do I, for that matter. I apologise if you
and others do not feel welcome; I unfortunately don't have time to monitor
the forums closely. Thorsten's approach and style are often combative but
as I say, he's not speaking for the project officially.

So, this post is on behalf of the project: developers are welcome to
contribute. We can't always take contributions (the megapov days taught us
that) but anyone wanting to improve the program in a meaningful way is
welcome here. Having forked versions in which new ideas can be tried out is
a good way to handle these patches and I'm happy to formally support this
(by providing server resources, forums, revision control, whatever else) if
folks are interested.

-- Chris Cason
   Team co-ordinator

Post a reply to this message

Chris Cason wrote:
> So, this post is on behalf of the project: developers are welcome

And this post is on behalf of myself:

I accept that not releasing the source earlier was unwise. It wasn't a
conscious decision per se (time just got away from me), but either way the
fault rests with me and I apologise to those who wished for earlier access.

I am seriously considering opening our revision control system for public
read access. The main issue stopping me is that I don't want to revisit the
same sort of issues that people flame us for already: they don't like our
type of 'free'. We use Perforce for revision control, which has free (as in
no cost to use) client software*, but is not Free Software such as SVN is.
I don't expect a requirement to have to install non "Free Software" to
access the repo would be very popular, and frankly I don't want to have to
deal with the inevitable complaints (as Linus's experience with a
proprietary SCCS showed).

While I could migrate to SVN (there is a p42svn tool), I'd prefer to wait
until 3.7 is finished if this is to be done (note I use SVN daily at work
and am in a good position to compare the two - I find I prefer Perforce).

I am looking into the logistics of providing a parallel svn repo that is
automatically kept up to date with the perforce one via nightly runs of
p42svn or some other similar system. I don't think this would be difficult.
Or if there was really enough interest from potential developers to make it
worthwhile, I would bite the bullet and change the project over to SVN
immediately - but given the content of this thread I am certainly not
holding my breath regarding the latter.

-- Chris


* The server normally costs money (if you want more than two users) but
  Perforce has kindly provided us with a free-of-cost license for most of
  the past decade under their policy of supporting open source projects.

Post a reply to this message

Chris Cason  wrote in message <48808a99@news.povray.org>:
> Please note that Thorsten speaks for himself when posting here (unless he
> explicitly says otherwise). As do I, for that matter. I apologise if you
> and others do not feel welcome

I do not think you need to apologize. And neither does Thorsten: everyone is
entitled to have his own vision of what the development of a project should
be.

Anyway, your message was very much welcome in this thread to calm things
down. Thanks a lot.

Post a reply to this message

Chris Cason  wrote in message <48809f34@news.povray.org>:
> I am seriously considering opening our revision control system for public
> read access. The main issue stopping me is that I don't want to revisit the
> same sort of issues that people flame us for already: they don't like our
> type of 'free'. We use Perforce for revision control, which has free (as in
> no cost to use) client software*, but is not Free Software such as SVN is.
> I don't expect a requirement to have to install non "Free Software" to
> access the repo would be very popular, and frankly I don't want to have to
> deal with the inevitable complaints (as Linus's experience with a
> proprietary SCCS showed).
> 
> While I could migrate to SVN (there is a p42svn tool), I'd prefer to wait
> until 3.7 is finished if this is to be done (note I use SVN daily at work
> and am in a good position to compare the two - I find I prefer Perforce).

I am very glad to read that, thanks a lot.

I think you could quell most of the complaints by saying everything out
loud: on the page with the instructions to get the source code, just write
something like:

"You can access the current source code using Perforce. Please note that
Perforce is free/gratis but not free/libre; a probable change for Subversion
is scheduled for after the release of the final 3.7 version."

I know I would be perfectly satisfied with such a message (although I would
grumble that I can not install a perforce client with apt-get), and I think
anyone sympathetic to free software would feel the same.

For just the same reason, I think that the intended licence change and the
reason for the delay should be written on the download page:

"Distribution and Modification of POV-Ray is governed by our distribution
license and source license. Please refer to those documents before
re-distributing or modifying any POV-Ray files. {+A change for a more common
open source license is scheduled for the 4.0 release.+}"

(with "scheduled" being a link to a FAQ entry explaining the impossibility
to change the licence when authors are missing)

This is not much, but just writing it on the visible pages would show even
FSF fanatics that you are aware of their concerns.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> "You can access the current source code using Perforce. Please note that
> Perforce is free/gratis but not free/libre; a probable change for Subversion
> is scheduled for after the release of the final 3.7 version."

  I'm not convinced it's the pov-teams duty to start nitpicking on
terminology and specifying whether some software conforms to whatever
the FSF wants it to mean.

  I think "perforce is cost-free" is more than enough, without the need to
go into terminology nor politics.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 18 Jul 2008 10:59:24 -0400, Warp wrote:

> Nicolas George <nicolas$george@salle-s.org> wrote:
>> "You can access the current source code using Perforce. Please note
>> that Perforce is free/gratis but not free/libre; a probable change for
>> Subversion is scheduled for after the release of the final 3.7
>> version."
> 
>   I'm not convinced it's the pov-teams duty to start nitpicking on
> terminology and specifying whether some software conforms to whatever
> the FSF wants it to mean.
> 
>   I think "perforce is cost-free" is more than enough, without the need
>   to
> go into terminology nor politics.

I would actually agree with this.  Just say the client is available at no 
cost and that's the solution that the team has decided to use.  I don't 
see a need to justify the choice of toolset.

Jim

Post a reply to this message

Warp  wrote in message <4880afcc@news.povray.org>:
>   I'm not convinced it's the pov-teams duty to start nitpicking on
> terminology and specifying whether some software conforms to whatever
> the FSF wants it to mean.
> 
>   I think "perforce is cost-free" is more than enough, without the need to
> go into terminology nor politics.

This is not cost and/or licence, this is also a question of convenience:

she-seel ~ $ sudo apt-get install perforce  
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Couldn't find package perforce

While every single computer I have access to already has a subversion
client. This is strictly a practical concern. The more obstacles you put to
the access to the source code (and having to install yet another * revision
control client is an obstacle), the less contributors you will have.

Which brings us back to the question:

Do you actually want contributors?

Post a reply to this message

Nicolas George wrote:
> she-seel ~ $ sudo apt-get install perforce  
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> E: Couldn't find package perforce

Yes, this is slightly annoying, though it could be resolved - perhaps by
perforce co-ordinating with the folks who manage the repos (though I
imagine that if it's not there yet it's not going to be). It's not that it
can't be available but that at least in your case (I presume you did a
apt-cache search?) the repository maintainers chose not to have it.

I use freebsd for povray.org and the official perforce clients (command-
line and GUI), plus the perforce C API (their protocol is fully documented)
are available via pkg_add (similar concept to apt-get), in addition to a
number of useful (sometimes third-party) tools; e.g.:

  c4             A CVS-like Frontend to Perforce
  cvs2p4         CVS to Perforce Converter
  p4.el          Perforce-Emacs Integration|
  p4api          Perforce API (static libraries and header files)
  p4db           Perforce Browser
  p4delta        Summarizes and manages diffs between local files and p4
  p4genpatch     Helper scripts for generating RCS patches from Perforce
  p4v            Visual client for Perforce SCM
  p4-P4::Client  Perl extension for the Perforce API|
  p5-VCP         A tool for copying files between various SCM repositories
  py24-px        Perforce p4 wrapper and Python Perforce interface|
  ruby18-p4      Ruby interface to the Perforce API
  tkp4           Tcl/Tk frontends to Perforce's p4

See http://www.perforce.com/perforce/loadsupp.html for more info about the
tools offered by perforce. There's also a p4ftp server which I could
install; this allows access to the repo from standard FTP clients.

> The more obstacles you put to the access to the source code (and having
> to install yet another revision control client is an obstacle)

Perhaps, but not much of one: installing the p4 client is as simple as:

  wget http://www.perforce.com/downloads/perforce/r07.3/bin.linux26x86/p4

which is the linux 2.6 x86 client, ready to run.

If installing p4 is enough of an obstacle to discourage someone from
developing then they might not get far with the POV source: it's not easy
to make effective non-trivial changes to the raytracer.

That said, I understand that it would be better if we had a svn interface.
As mentioned, it's under consideration.

-- Chris

Post a reply to this message