Hi maintainers of packages, Hi folks,
maybe some thoughts on Radiance and its situation, from someone who had watched this from the periphery for a decade or two. Maybe it saves you some high blood pressure when "fixing other people's code".
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.
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.
c) Radiance's situation is somewhat similar to Cyrus IMAP, which had been developed by Carnegie Mellon, and which had its Achilles heel of a substantial lack of docu around 2005. That was only overcome by CM getting some funding to further care for its baby (as far as I know). Radiance is viewed by LBNL (www.lbl.gov) as their baby, which at least is true for the code distributed by the release process on radiance-online.org. LBNL had never, to my knowledge, gotten funds for support or even further development of code. And both the number of developers and the size of the community are much smaller than for Cyrus, Apache, GNU tools or similar projects. Think two orders of magnitude here.
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.
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.
In any case:
Getting Radiance to move is not so much a problem of suggesting new technology, but getting funds to pay folks who know what to do and putting them in a framework to do so over a reasonably foreseeable time interval.
thanks for your interest, best regards
Peter
ยทยทยท
--
pab advanced technologies Ltd, http://www.pab.eu