[IPOL discuss] revision of the Software Guidelines - first draft

Nicolas Limare nicolas.limare at cmla.ens-cachan.fr
Sun Aug 19 13:38:31 CEST 2012


Hi all,

I would like to suggest a few updates to the current IPOL software
guidelines. My first draft is available online:
-> https://tools.ipol.im/wiki/ref/software_guidelines/drafts/

The changes from the previous version are listed and briefly
hereafter. I would like to have your feedback and propositions for
other changes, either privately or on the list (if you think some
discussion can be useful). I will collect all these remarks and
propose a second draft after two weeks.

Thanks

8<----------8<----------8<----------8<----------8<----------8<----------
Changes from Version 1.00

* Add a license for this document.

  I think some collective reflexion and some experience were
  involved in these guidelines, and they may be useful to
  others. This license (CC-BY) clarifies how the guidelines can be
  reused.

* Remove some mentions of IPOL, for generic guidelines.

  Same as the previous point.

* Recommend a compilation without warnings.

  There is no reason in general for compiling with compiler
  warnings, so they should be avoid. Previously, this was implicit
  via a footnote. Now it is explicit.

* Mention GPU-accelerated computing.

  This topic is often raised with IPOL. Now GPU is mentioned: CPU
  code is possible, but it won't be reviewed, the software must
  work without GPU, anf the demo server has no GPU.

* Clarify the use of external libraries packaged with the software
  (foreign code).

  This covers cases like the use of Eigen, or other libs, as
  building-blocks for an IPOL code. Such libs must be C/C++,
  standard and portable, and their usage should be isolated from
  the author's code. I would like to add a condition on size, like
  "no huge library for a tiny algorithm", but I couldn't find a
  good expression.

* Recommend additional compiler variables for make.

  Without the C89 and C99 variables we can not have some automated
  tests of the code.

* Require correct exit codes and robust command-line processing.

  If the command-line behaviour is always correct, then we can
  simplify the python code for the online demos and remove all the
  parameter tests.

* Add the CC0 dedication to the list of possible license terms.

  CC0 is like public domain, but with worldwide validity. IPOL
  authors may want to use this license for trivial code, or more.

* Require a list of the files and known defects in README.txt; allow
  this file to be split.

  the list of files includes what is and what is not reviewed; long
  README.txt could be split in shorter files.

* Recommend to replace tabs by spaces.

  This avoids choosing if tabs are 2, 4, or 8 characters. 

* Fix some typos.

  Including an errata for RFC2119.

-- 
Nicolas LIMARE - CMLA - ENS Cachan         http://limare.perso.math.cnrs.fr/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20120819/586f85f4/attachment.pgp>


More information about the discuss mailing list