Tasks

From wiki.zmanda.com
Revision as of 18:08, 24 December 2007 by Dustin (talk | contribs) (New tasks)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Stuff that needs doing. Tasks with no "owner" are open. To "claim" a task, edit this page and add your name as "owner", and email your thoughts to the amanda-hackers list. Other hackers will be happy to help. If you have other tasks, please add them here, following the pattern below.

Perlification

There is no shortage of stuff to rewrite in Perl. This is just a sampling of the "low-hanging fruit".


Difficulty: low
Skills: perl
Owner:
a - t

Rewrite amgetconf

amgetconf is a fairly simple C program (server-src/getconf.c). Rewrite it in Perl, using the Amanda::* modules. As a first draft, just replicate the fetching of configuration parameters. Once that's completed, work on the build parameters and debug-log management. Unit tests are already functioning against the C version -- the perl version should pass those tests too.


Difficulty: medium
Skills: perl
Owner:
a - t

Update amtoc

amtoc is already in Perl, but it parses logfiles directly. Update it to be more readable, to use Amanda::Logfile to read the logfile, and to produce correct output. It will need new unit tests.


Difficulty: medium
Skills: perl
Owner:
a - t

Rewrite amlabel

amlabel is fairly simple: use the changer to load the correct tape, check for an existing label, and write a new label. It will need new unit tests.


Difficulty: low
Skills: perl
Owner:
a - t

Rewrite amtape

amtape is basically a user-friendly interface to the tape changer, and should be easy to rewrite in Perl. It will need new unit tests.


Difficulty: med
Skills: perl, swig
Owner:
a - t

Write Amanda-Holding

The holding module (in server-src/holding.[ch]) needs to be interfaced to Perl, after which amcleanupdisk can be rewritten in Perl. The new module should come complete with POD and unit tests.

Build Process


Difficulty: high
Skills: autotools, libtool, perl linking, portability
Owner:
a - t

More portable Perl extension building

The current build process uses the -I flags from perl to find perl.h, but then uses Libtool to do the final linking. This seems to work on most platforms, but there may be a better way. The problem with using MakeMaker, Module::Install or Module::Build is that they assume that the compiler which built perl is still available. This is not the case on platforms like Solaris. A "hybrid" solution -- which tests the native-perl method, and falls back to the current Libtool method -- may be best.


Difficulty: high
Skills: autotools, libtool, perl linking
Owner:
a - t

Simplify Perl Automake rules

The Makefile.am stanza to build a perl extension from a SWIG input file is too long. Ideally, this could be expressed in a few lines giving only the source file and binary dependencies of the extension.

Miscellaneous


Difficulty: medium
Skills: perl, web, subversion, cron
Owner:
a - t

Make POD available on the web

The new perl modules all contain POD (plain old documentation), but this is currently only accessible via 'perldoc' against an installed copy of the modules -- not too convenient. Ideally, the POD from the latest committed code would be available somewhere on the web, such that it can be linked from this wiki. Zmanda can provide hosting and other infrastructure for the result.