[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Presentation of Debian Med on local Next Generation Sequencing workshop (April)



On Fri, 21 Mar 2014, Charles Plessy wrote:
> For packages without upstream tests, in the meantime, even the most simple
> tests like running the command with the --help option, are potentially useful.

+10 ;)  I also try to run some Demo or Example script if such is
provided (often via xvfb) to indeed catch the most broken beasts

> My favorite example is T-COFFEE, where we were distributing a 100 % broken
> package on arm for years.  With autopkgtest, we will have a better overview on
> what package works where (just a successful build is not enough), and this will
> help people to evaluate the feasiblity of projects based on Debian on amd64,
> and also on more rarely used platforms (such as the Raspberry Pi as we read on
> this list).

well -- the best one IMHO here is the s390x -- big-endian 64bit.  It
helped to detect/iron out bugs for cases where unit-tests were not
developed to test those corner cases, but which naturally appear
when e.g. bytes get swapped ;)  armel is my favorite to detect race
conditions, since it is somewhat slower than regular x86, thus those
race conditions do not come that obvious ;)

> Slightly more complex tests can often be built from the examples in the
> program's README.  On my side, I am still on a learning phase with autopkgtest,
> but I hope that collectively we will have a clear vision on what to recommend
> Upstream so that they can write or accept user-contributed tests are trivially
> run by autopkgtest.

well -- autopkgtest is indeed nice BUT for basic QA I do prefer
build-time testing, since that guarantees that package with known issues
doesn't even get to the users before issues get resolved.  And it goes
through testing on all supported architectures (if not architecture all
of cause).

My main reluctance with autopkgtest was the need to duplicate definition
of 'running tests' twice in debian/rules and then under debian/tests...
sadt seems might be of help to avoid this duplication now -- I will look
later to see if that would be possible to just call it (with
corresponding tune up of PATH/PYTHONPATH) with debian/rules...


> I also like a lot the “litteral programming” side of the “reproducible
> research” trend.  I am developing some tutorials based on real data analyses
> from my work, which are currently implemented in knitr
> (http://yihui.name/knitr/), and which I hope to iron out so that they can be
> used to test a Debian image in an integrated way.  However, they currently
> still use programs that are not yet packaged.

ha -- being not R user much -- haven't heard about knitr.  Looks
interesting indeed.

Python folks were blessed "recently" with IPython which now goes even
stronger forward (thanks to support from Sloan foundation and others).
If you managed to not hear about that: have a look at sample ipython
notebooks at http://nbviewer.ipython.org/ .

> Work in progress but comments welcome !  https://github.com/charles-plessy/tutorial

it is pity there is no some kind of 'knitrviewer.org' ;)

-- 
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        


Reply to: