On Tue, May 12, 2009 at 08:05:35AM -0400, David Golden wrote:
> 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...
>
> 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?
All of it should be carried over, but choice of editor should default to
just looking at $EDITOR at runtime. Needs to be configurable though in
case you're using a platform where setting that isn't customary, such as
Windows.
I suppose you could drop configuring whether to sent duplicates, as
sending 'em would, I think, *always* be the wrong thing to do.
> Should config files be human readable/editable or should they be
> structured data (e.g. JSON)?
Yes, and yes. Sorry :-) Thankfully, YAML is both, and JSON can be too
provided it has suitable whitespace. There's also no particular reason
that I can see why to not just serialise a perl structure out to disk
Data::Dumper-stylee - that has the advantage of not requiring that YAML
or JSON be available in the testing environment.
> (I will note that JSON will be a
> prerequisite for Metabase and will thus be available for CT config as
> well.)
Ah, OK. In that case, use JSON, not YAML.
> My working hypothesis is that there should be a unified ".cpantesters"
> directory in the users home directory ...
Aye.
> 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.
Yes, the multi-version multi-platform aspect is crucial, as it means
that all of a user's config info can be stored in a home dir that gets
mounted using NFS or similar on several different systems.
Also consider multiple concurrent testing runs (of different
distributions, obviously) using the same version and architecture. This
means that you can't just read the history file at startup, writing
additions to disk but not re-reading the file. You need to 'tail' the
file to spot additions by other processes. Or at least make it easy for
someone else to add that later when they need it.
Note that using filenames (eg creating files like
5.8.9--Foo-Bar-1.23.tar.gz--linux--blah-PASS) to store this info probably
won't do the trick, because that will lead to an explosion of files, vast
numbers of inodes, and people running up against filesystem quotas.
Even if the files are zero-length, quota systems generally ration both
space and number of files.
> 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).
Not sure what you mean by this.
--
David Cantrell | top google result for "internet beard fetish club"
Suffer the little children to come unto me, as
their buying habits are most easily influenced.
-- Marketroid Jesus
