On 11/21/12 3:17 PM, Jordi Gutiérrez Hermoso wrote:
On 21 November 2012 14:55, Steven G. Johnson<address@hidden> wrote:
On 11/21/12 11:47 AM, Jordi Gutiérrez Hermoso wrote:
But after you do the patch, how will we incorporate it back into our
own codebase, if we have a copy of it?
"cp Faddeeva.cc octave/...../Faddeeva.cc" is pretty easy...
What if you become unresponsive to accepting patches?
Then you are even more screwed if you link to it as a separate library
shipped by me, because then you can't merge your changes at all.
What if I
already had patches there? Then I can't just overwrite the local copy,
I'd have to do merges instead. And also, I or someone else in Octave
has to be remembering to periodically do this copy and make sure that
something has changed.
Instead, users periodically check my site to see if something has
changed, and re-install the shared library if necessary. Which do you
think they will update more often, Octave or some obscure little library
they've never heard of?
Moreover:
1) Code like this doesn't change very much over the long term. It is not
likely to get much in the way of new features (except for new language
interfaces), and bugfixes should tend to accumulate very slowly over
time (probably slower and slower over time as it "converges").
2) It is easy for me to send a message to the octave mailing list, or
submit a bug report, if I have a bugfix. I am already doing this for
SciPy. It is much harder to publicize the need for users to download an
updated version of an obscure little library to users, distros,
etcetera. As long as I am maintaining the code upstream I will continue
to do this; if I were to stop maintaining the code then you won't have
any more patches to merge anyway.
3) Other than Octave and possibly SciPy, it is not clear who would use
it in library form. Most scientific programmers that I know are very
unsophisticated about libraries and it is much easier for them to just
make a copy of the C++ code and link to it directly rather than
installing a shared library (which they only do by necessity for large
packages). And SciPy may well prefer to just include their own copy of
my source, as they are doing now, so as not to introduce an external
dependency; certainly no one on the SciPy lists mentioned any interest
in me shipping a shared library.
Please, don't trivialise this problem. I know software distribution is
a chore and hard work, but it can't be avoided.
I'm not trivializing it, I'm simply suggesting that standalone libraries
are not necessarily the best solution for distributing relatively small
self-contained numerical subroutines like this. The question is, what is
the best software distribution mechanism for this problem, considering
users as well as developers?
Look, it is easy for me to make an autoconfiscated tarball if that is
what you really want. It's not a significant chore (the Makefile.am and
configure.ac files would only be a few lines long). I just don't think
anyone other than you would want this in shared-library form, so what
you are asking for doesn't make a lot of sense to me.