Re: [MoM] Fwd: Outreachy 2016 application
Hi Anna,
On Fri, Feb 19, 2016 at 12:05:21PM +0300, Anna Lioznova wrote:
> Thanks for the letter! It's my pleasure to work with such a team!
:-)
> I configured RSA key for alioth and checked that it works.
> I'm not a git expert, but I'd like to start with git rather than svn -- I
> think I can change it anytime if I'll face problems.
If you are new to both I'd recommend to concentrate on Git.
> I read the Debian Med Policy document. Currently I have no questions, but
> they'll probably arise while working on the project.
Sure.
> I checked out bwa package with git, so I have a local version. What should
> I do next?
May be it makes sense whether your build environment works well. So trying
gbp buildpackage
should create a working package for you.
Than you should definitely have a look at the website which describes
all things behind the "Continuous Integration" in Debian - which means
the package testing. Specifically the Documentation part at this page
is for you.
Finally we have a good amount of packages maintained by the Debian Med
team which just have a test suite. If I do
find . -type d -path "./*/debian/tests" | sort
on my local hard disk with several package clones I get 69 results. Not
all of them might be sensible examples for a beginner but looking into
examples is probably the best way to learn (I personally in most times
copy an example to create a new test).
To pick some *random* examples from this list to not throw the whole lot
on to you, I'd recommend cloning the packaging of the following packages
to have some working examples:
aegean
axe-demultiplexer
artfastqgenerator (package is in new queue)
eigensoft
here Petter Reinholdtsen added a very simple test: calling
the binary and see whether it prints the usage message
So tests can be *very* rudimentary and specifically this one
should be enhanced but you get an idea what is possible
plast
The test is basically a script provided by upstream with
PATH adjusted
I *personally* always call the test script debian/tests/run-unit-test
but the test name can be any name you set in the control file. I'm
usually adding the test script also to the binary package and add a
README.test file where I explain how a user also can easily run the
test script on the actual computer which on one hand proves the
functionality and on the other hand might be a simple usage example.
Usually you start be reading upstream docs for usage examples and just
turn this into code. If upstream does not provide such example its up
to your experience with the program - you said you are a bwa user and
thus you know what you expect from the program. Find a **freely**
**licensed** test data set process it and compare the result with an
expected outcompe (while the comparison might be tricky since sometimes
time stamps or other things prevent a simple file comparison).
If there are no free data sets at hand may be *generating* a new data
set could be helpful. For this purpose I just injected packaging for
artfastqgenerator (in New queue) and art-nextgen-simulation-tools
(license needs to be clarified - mail was just on the list).
Hope these hints are helpful so far - feel free to ask for more
details
Andreas.
--
http://fam-tille.de
Reply to: