|Title||Adding or changing configuration parameters is hard and error-prone|
|Assigned user||Gareth Rees|
|Description||If you want to add or change a configuration parameter, you have to update it in many source files, and the more supported defect trackers there are, the more places you have to change it. This make it costly to maintain the P4DTI.|
|Analysis||You have to update these places:|
2. init.py (once for each defect tracker)
3. configure_DT.py (three for each defect tracker)
4. dt_DT.py (once for each defect tracker)
So a total of five places need changing for each supported defect tracker, plus one.
Instead of passing configuration parameters about explictly, files could always "import config" and refer to them as config.parameter. This would be a useful piece of documentation; it would also make the configuration method easier to document, and advanced configurations easier to build, since you'd only have to mess about with a parameter or two here and there instead of trying to build complete configurations.
|Evidence||Noticed while adding log_level parameter.|
The default values for parameters in configure_teamtrack.py can disguise errors; see change 9979 for an example: <
|Created by||Gareth Rees|
|Created on||2001-03-14 16:14:00|
|Last modified by||Gareth Rees|
|Last modified on||2001-12-10 19:31:16|
|History||2001-03-14 GDR Created.|
|10036||closed||2001-03-15 19:37:47||Gareth Rees||The replicator configuration is passed around consistently as a module (usually called config) rather than in a multitude of named parameters or as a dictionary.
Formatted init.py as a document. Generic configuration parameters are checked here. Check rid and sid using check_config.check_identifier().
Formatted p4.py as a document. The p4 class takes its parameters one by one, rather than as a dictionary. The run() method takes a dictionary as the second argument, rather than a list of one element, that element being the dictionary.