On Aug 10, 2007, at 2:23 PM, Ethan Mallove wrote:
Looking a little closer, there are inconsistencies in what's
going to the saved .dump and .ini files:
Test Run .dump (split up by variants):
* Everything (including stdout/stderr)
Test Run .ini:
* Nothing
That sounds fine.
Test Build .dump:
* Everything (except stdout/stderr)
Test Build .ini (split up by test suites):
* Everything execept database serials, mpi_name,
and environment (e.g., prepend_path, env_module, etc)
This .ini might be a remnant left over from prior days; I
unfortunately don't remember...
Should we save the stdout/stderr in the .dump, and then the .dump
would have *everything*?
MPI Install .ini:
* Nothing
MPI Install .dump:
* Everything
How about we put *everything* in the .dump files, while
offering to also save *everything* in INI files in the [MTT]
section? Though Perl-Dumper is only slightly less
human-readble than INI.
Actually, given what you've shown above, I'd be ok ditching the .ini
files altogether.
These are also a little confusing:
save_stdout_on_success
stderr_save_lines
Don't we want these instead broken up into two: inifile and
mttdatabase? So a user might choose to save more or less on
their disk than to the database?
save_stdout_on_success_to_mttdatabase
stderr_save_lines_to_mttdatabase
save_stdout_on_success_to_inifile
stderr_save_lines_to_inifile
I always viewed the .dump file as a 2nd copy of whatever we send to
the reporter (not just the mttdatabase). So I kinda thought that
they should save the same thing, and you could use the .dump file to
resubmit to the reporter if you ever needed to (we've made a few
attempts at resubmit over the years but never wrote a comprehensive/
easy-to-use resubmit tool).
--
Jeff Squyres
Cisco Systems
