I have gotten the priviledge of maintaining the module XML::Conf for the late Ariel Brosh. This is a marvellous opportunity for me to get to learn to work with CPAN from the other side - and probably the reason why I asked for the 'job' in the first place.
Well when I initially examined XML::Conf for the first time, I just thought, well this module just needs some docs and some tests, but as I am working on the 0.03 version of the module, the Changes and TODO lists have become quite long.
This is the Changes and the TODO at the time of writing:
0.03 Sat Jan 18 18:48:43 CET 2003
- Development taken over by jonasbn
- Everything put under revision control
- Added README file
- Added TODO file
- Added INSTALL file
- Added AUTHOR file
- Added LICENSE file
- Added CVS tags to everything
- Restructured distribution structure
- Added t dir
- Added lib dir
- Added lib/XML dir
- Rewrote test.pl
- Added use of Test::More
- Added t/basic.t
- Added prototypes to all methods
- Added NAME, DESCRIPTION, TODO, AUTHOR and COPYRIGHT paragraphs
- Privatized the subs: val, setval, newval and delval
$Id: TODO,v 1.1 2003/01/18 18:39:09 jonasbn Exp $
- Restructure distribution for easier use of test files as actual Unit-tests (will ma
ke it easier for me to maintain the module).
- Write tests
- Write documentation
- Add SYNOPSIS material when the tests are done
- Rewrite constructor to be able to handle a 'new' configuration and not just an existing.
- Make regression tests to find minimum versions of Tie::Hash and Tie::DeepTied
- Talk to Gabor (or whomever maintains Ariel Broshs HTPL distribution) about sepearating some of the modules, I for one need the Tie::DeepTied.
I have started by restructurizing the distribution for me to better have an overview of what is going on. Then I have started making unit-tests of the more basic methods to get a hang of what is going on. I am not the kind of guy who can read code as if it is a good book, I need hands-on experiences.
The task has proven a bit more complex than I thought, and trying to understand a module just for the sake of testing and documenting it is a bit more difficult than I thought.
Normally when I write or use a module I do it for some kind of reason, which is more pragmatic. But I guess that as soon as I get to know my way around this module things will speed up a great deal.
My goal is to have added unit-tests and documentation of all methods before I send this of to CPAN in a version 0.03.
BTW as you can see in my TODO I have added a bullet called regression testing, this project have spawned of a new project for me, a regression test framework, I will probably start on this as soon as 0.03 is shipped and I can start in some of the more 'interesting' tasks...
