TODO list for Perl module CPAN::Reporter

#--------------------------------------------------------------------------#
# Bugs
#--------------------------------------------------------------------------#

#--------------------------------------------------------------------------#
# Features, etc
#--------------------------------------------------------------------------#

# High priority

# Medium priority 

- refactor t/Helper.pm

- add earlier, successful phases to output in reverse order.  Probably have to
  bump up the test-length cutoff, though, to deal with lengthy make output
    - Test phase output
    - make phase output
    - PL phase output

- For failure in PL stage -- show configure_requires and an error message
  that other requirements aren't available if PL fails

- set alternate configuration file/dir via environment variable (RT#30314)
  e.g. PERL_CPAN_REPORTER_CONFIG 

- Add config to save reports to a file (Jerry Hedden) (RT#24816)

- Log entire history of reporting, regardless of whether a report is sent
  (David Cantrell) -- i.e. keep discards somehow ("DISCARD" just like rest 
  of subject line?)

- public API for CPAN::Reporter::History for external querying 
  (requested by Andreas; Cantrell)
    e.g CPAN::Reporter::History->have_tested( 
            dist => $dist, grade => "pass", perl_version => "$]"
        )

   "The result could be an array of hashes or light objects that
   know about all 5 (or more) constituents of a line in the history file.
   If some qualifying parameter is missing, this could be taken as ANY. I
   think this provides about everything I would ever need." -- Andreas

- add test_timeout to CPAN.pm

- Don't cc author if running under bleadperl

# Low priority


- add link to Wiki for UNKNOWN (and NA) reports

- add warnings::compat to toolchain or else add config to allow local
  modules to be added to toolchain report
    - SAPER: 
        Hmm... ok. The fact is that warnings::compat isn't listed in
        Sys::Syslog prereqs, but it should in order to make it work under
        5.5. So I guess that Slaven manually installed it in his 5.5.5 smoker
        in order to ease the process, but in that case, it becomes (in a
        sense) part of the toolchain, because it masks a potentially missing
        prereq (this is what happened here). warnings::compat is a little
        special because it provides a way to make a core module available on
        old Perls. So maybe CPAN::Reporter should allow one to add locally
        installed modules in the toolchain section.
    - SREZIC:
        To add my 0.02EUR: maybe warnings::compat could/should be shown only
        if 5.5.x is used.

- add CC recipients to output message "sending test report... to..."

- change report truncation to take first 25K and last 25K (summary) (?)

- figure out how to support color output from Test::Harness 3.0 -- probably
  set an environment variable to get them to pass color strings to the pipe
  and then strip color escape codes from the teed file.

- switch from a single flat file for history. e.g.
    - SDBM_File for history (key on subject line, with phase as value?
      Or key on distro name/perl with result and phase as value? ) -- but
      does it scale well?  (See MJD's article)
    - Or use sorted file with Search::Dict(?) -- (prefer this option,
      keeps search for non-existant line fast; insertion is a just a few
      block writes and a rename.) If we do this, need to put distro name
      first to make "have_tested()" easier to write
    - Use filesystem to index -- one file per distname? hash with directories
      to keep number of files/directory down?

- add timeout to prompt (RT#28034)

- Add interactive config for editor?

- Improve test coverage for utility subs and error handling

- Check email addresses for validity (cf. Email::Valid, etc.)

- Other Config items like make or cc

- heuristics for missing library files --> discard report

# Probably won't implement

- Check if CPAN::Reporter is reporting under a "force X" command?  It
  probably shouldn't.  Is that a CPAN.pm change?  Or can I get it from 
  the dist object? ie. $dist->{force_update} (DAGOLDEN)  -- on reflection,
  as long as we're checking prereqs and discarding, this may be OK

- send duplicate report if using "report" (?) or "force" (?)

- ability to turn on/off via an environment variable (David Cantrell)

- ability to only report on what I asked to install, not on its dependencies
  (David Cantrell)

- use environment variable and/or external file to indicate modules to 
  skip for reporting
