From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-08-11 12:09:34
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