On Mon, 10 Mar 2014, Timothy Coalson wrote: > > � �As a quick update, we are aiming for the next workbench release > (v0.85; > > � �cifti-2 compatibility), including source code, to occur in about a > month.
> That is great -- thanks for the update! > It would be especially nice if source release would be > accomplished with build(dependencies)/installation instructions, > thorough overview of copyright/licenses for any 3rd party code bundled > in (if any), and (unit)tests battery to verify its correct operation. > You don't ask for much, do you? hm.... -- nope I have asked nothing beyond commonly accepted practices in FOSS development (e.g. INSTALL, LICENSE, and README files) + bits to bring some assurance of correct operation (read -- correct results, reproducibility, etc). > We do plan to say what the build dependencies are (QT4, configured with > the components we use, and OSMesa if you want wb_command -show-scene) and > how to build (cmake), and installation shouldn't be picky as long as the > libraries as configured for building are found - we don't currently have > any preferred method of installation, and it doesn't need to be co-located > with any reference data.� We can note bundled 3rd party code in some file, > maybe in the README? sounds good > �I'm having trouble finding info on how this is usually done. There is no a common standard. As hinted above, INSTALL (or section in README) could indeed describe build/installation instructions. As for copyright/license information -- since there is per se no standard -- if you could furnish it in the format we use in Debian, that would be just awesome: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ it is machine readable, concise, and easy to parse visually. > As for unit testing, we have a few tests on some of the simpler classes, that is already great for a start > but not full unit tests (and testing most of the processing code, such as > volume to surface mapping, would require data files). for the volume to surface mapping unit-testing, it might be enough to "simulate" the necessary data structures on simplistic structures (e.g. sphere and a few voxels). E.g., that is the approach we (or to say more precise - credit should go to Nikolaas N. Oosterhof) took in PyMVPA: http://github.com/PyMVPA/PyMVPA/blob/HEAD/mvpa2/tests/test_surfing_voxelselection.py But, I guess, it would be great if some simplistic (simplified) data files for testing basic I/O could also accompany the source base to provide rudimentary I/O testing etc. But all the latter ones could follow -- and that is great if you already have some unit-tests in place. Would be interesting to see how you wrapped all those up with cmake -- ITK, CMTK and ANTs have quite elaborate test drivers for their ctest's -- so they might be of interest/relevance here too. Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
