Hi!
a) getting Radiance into distributions, IMHO, is very helpful and much
appreciated by anyone in the community. This will get the tool to the
end user more easily.
I could ask the Fedora people if somebody would be willing to maintain it in
Fedora, but usually that needs somebody who is willing to keep a spec file
uptodate and test it. Which requires somebody who knows at least the basics of
radiance... If somebody from the radiance community is willing to work on it, I
could bring them into contact with some people from Fedora.
Since radiance is in Debian and Ubuntu we have more and more installations -
here are the popcon stats from Debian for example: http://deb.li/n7tU
b) Radiance code is not always easy to handle, e.g. since the built
process never followed the mainstream. On the other hand, when it
started, the now standard "configure; make" sequence wasn't mainstream
anyway. If you never got mad over "string.h" versus "strings.h", you're
lucky. Apache, the Linux kernel, all more modern.
Most build systems are fugly in some way. Automake and friends are a pain in the
ass but you can make them work very well. CMake doesn't support that many
platforms and I find it pretty confusing, too. Same for SCons, which is at least
written in Python...
In the debian/rules file I'm using the RMakefiles, but I've patched a lot in
them before it was easy to use for building the packages with them. Thanks to
Greg the patches are applied in CVS these days. Took me some time to figure out
what the best way is to build the packages, but it was not too hard to do.
d) There are a number of enhancements that would be very useful to have
in Radiance: Algorithmic features that actually extend the work that can
be done with Radiance, thoughts on getting the code more modular, built
process, test process. For me, for example, the first would be the
utmost important. For you, packaging comes with other priorities. In
regard to some emails lately, please be prepared that your view might
not be the greatest common divisor among Radiance users or folks concern
with Radiance development.
Having a test framework would be *really* nice. I'm always wondering if we hit
alignment or endianess or other issues on the various platforms which are
supported by Debian.
e) make, dmake, gmake, RCS, GIT, subversion etc. : All nice and cool and
useful. Newer tools could be used to Radiance's advantage. If you want
my two cent recommendation on how to get them: Explain to LBNL why
Radiance differs from other packages that you maintain, what the
advantages for the end user are (e.g. thinking of 'correct' version
numbers like 4.5.0.1 instead of 'HEAD from 11/12/2010' when Radiance is
included on Debian's next release), and how many people are potentially
using your release (estimated numbers for your distribution).
The situation that Radiance is included with Linux distros is
comparatively new to Radiance. If you require principal changes to the
upstream system, explain the advantages for the end-user and yourself
(see last sentence) to folks managing the funds. Same goes for Solaris,
Windows, Mac, etc.f) Most any release process can be streamlined. The RCS/CVS I added in
2003 on the then pirate-state radiance-online, is by no means cast in
gold. It had been a step forward from the very first SCCS and came after
an intermediate interval with no source revisions. Maybe CVS can be
extended or used more fully, maybe another tool is more powerful.
I'm all for having a properly maintained git with redmine or some other tool as
bugtracker. I wouldn't even mind to host it...
Cheers,
Bernd
ยทยทยท
On 11/30/2010 08:08 PM, Peter Apian-Bennewitz wrote:
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F