Hello,
From: "Matthew W. Roberts" <ma...@ne...>
# I know this is a bit old...
#
# > > One more thing -- are we still planning on setting up a separate
# > > matcompat directory? I'd like to upload Paul Kienzle's scripts into
# > > the repository.
# >
# > I wouldn't use a separate subdirectory, we should merge the files in our
# > directory structure.
#
# The problem with this is that when a new version of matcompat is
# released (as just happened last month) we have to go back and figure
# out again where we put the files.
#
# > If we want to release a matcompat package we can use some Makefile magic
# > to bundle the appropriate files.
#
# Sure, but it seems that it would be a lot easier to just keep them
# in a separate directory.
#
# > Have you talked with Paul about that?
#
# No, but I will contact him.
I was writing a paper lately and the first question was : "what are
the claims?" Once this is settled things are straightforward.
What are the claim of the Sourceforge Octave repository?I feel it
is caught between the Octave distro and individual developers. How
should a endish-user look at it?
The official distro is stable and installs through 'make install',
or by installing a binary package. Functions are accessible through
the command line, doc through html/texi/ps.
This way of installing is simple to understand.
Individual developers produce extra m-files, .cc files, patches,
usually without a Makefile or any installation procedure. In the
best of case, the user just puts the m-files within his LOADPATH.
Otherwise, he produces a .oct file and puts it within LOADPATH
(right?). Or else, patches the source octave tree and re-does "make
install".
This requires more work from the user.
One possible claim could be : "Allow end-users to get a desired
functionality easily". Another could be "Provide links / archive of
all contributed octave development". Or is it something else?
Cheers,
Etienne
|
