I'm going to start working on CPAN::Testers::Client very shortly. This is intended to be the new, unified client that brings together the logic that is currently split between CPAN::Reporter and CPANPLUS. Reports will be structured data instead of just text. It will be responsible for sending reports to a Metabase repository.
I'd like to get input on an approach to managing CPAN::Testers configuration data since getting it wrong now means a lot of re-work down the line. This is a bit of a brain dump, so thank you in advance for your patience in reading through it and I would greatly appreciate your reactions. Right now, CPAN::Reporter and CPANPLUS each maintain configuration data independently in their own directories and their own ways. They both support these: * Tester email address * SMTP server CPAN::Reporter supports several additional options. Some of them can have different defaults depending on the 'phase' (PL/make/test) and report grade. * Whether reports should be edited * Whether reports should be sent * Choice of editor * Whether duplicate reports should be sent * Skipfile (of regexes to match against AUTHOR/TARBALL) * Transport subclass and arguments * Timeout for commands captured through CPAN::Reporter CPAN::Reporter keeps a history of reports that were previously sent in its configuration directory. Configuration directory and configuration file can be overridden with environment variables. So the question for me is: how much of this should carry over to CPAN::Testers::Client? How much is necessary? Can anything be discarded? What should remain within CPAN/CPANPLUS configuration and what should be unified? Also, to the extent there are configurations in CPANPLUS::YACSmoke, should any of it migrate into the unified client? Should the unified client support extensible configuration by automated testers? (E.g. a config file with sections for YACSmoke or PoCos or whatever) Should config files be human readable/editable or should they be structured data (e.g. JSON)? If the latter, I would imagine they would need to have a module API and/or interactive configurator (e.g. a 'cpan-testers-config' program)? (I will note that JSON will be a prerequisite for Metabase and will thus be available for CT config as well.) My working hypothesis is that there should be a unified ".cpantesters" directory in the users home directory (as defined by File::HomeDir->my_home) unless an environment variable directs elsewhere (CPAN_TESTERS_DIR=...). This directory will contain a config file and a Metabase user profile file. (In Metabase, users are represented using a particular data structure, not just a user identifier and password.) The .cpantesters directory will also contain the history of reports sent, probably in a subdirectory and probably divided by version/architecture for search efficiency. (If you're running perl 5.10.0 on i686-linux, there's no point searching for duplicate reports from 5.8.9 on i686-linux-64int-thread-multi.) If there is a skipfile, it should also live in that directory. I think that CPAN/CPANPLUS should only have a general "testing on/off" switch. Almost everything else should live in the .cpantesters config file. The exception would be command timeouts, which should be handled by CPAN/CPANPLUS, not the CT client. Another exception would be the choice of editor, as a goal for the CT client is to be "UI-neutral" and use callbacks for user interaction. I think it makes sense to allow the CT client config file to have "sections" for automated testing clients, but that change may take a while to happen (if it happens at all). I'd appreciate your thoughts on this ramble. Regards, David
