List of Known Issues for a particular release

List of Known Issues for a particular release

[Mark T. Ortell]

Hello,

I am doing a software tool assessment for functional safety and I am reviewing the use of Git as the SCM. One thing that I need to do is review the list of "known issues" with the Git release being used. I have gone through the release notes and found that it only contains the fixes and enhancements in a particular release of Git, it does not contain a list of known issues/errata in a particular release. The github project also does not include the bug tracking list, so I am not able to figure out a way to review the known issues for a particular release. I considered reviewing the fixes in releases beyond the release used, but that has 2 problems. One, it doesn't contain any issues that are yet to be fixed. Two, only the fixes in the "next" release are truly relevant because fixes after that could have been introduced in a release after the release being used. An additional note is that the Git for Windows project does provide a list of known issues in the install 

Could someone in this mailing list assist me in finding the known issues for a particular version? 

Best Regards,
Mark Ortell

Re: List of Known Issues for a particular release

[Elijah Newren]

On Thu, Jul 11, 2019 at 8:50 AM Mark T. Ortell <mtortell@ra.rockwell.com> wrote:
>
> Hello,
>
> I am doing a software tool assessment for functional safety and I am reviewing the use of Git as the SCM. One thing that I need to do is review the list of "known issues" with the Git release being used. I have gone through the release notes and found that it only contains the fixes and enhancements in a particular release of Git, it does not contain a list of known issues/errata in a particular release. The github project also does not include the bug tracking list, so I am not able to figure out a way to review the known issues for a particular release. I considered reviewing the fixes in releases beyond the release used, but that has 2 problems. One, it doesn't contain any issues that are yet to be fixed. Two, only the fixes in the "next" release are truly relevant because fixes after that could have been introduced in a release after the release being used. An additional note is that the Git for Windows project does provide a list of known issues in the install
>
> Could someone in this mailing list assist me in finding the known issues for a particular version?
>
> Best Regards,
> Mark Ortell

Probably not in the format you want, and likely including noise that
isn't relevant, but in a clone of git.git you could run:

git grep ^test_expect_failure t/

Re: List of Known Issues for a particular release

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On 2019-07-11 at 15:28:27, Mark T. Ortell wrote:
> Hello,
> 
> I am doing a software tool assessment for functional safety and I am reviewing the use of Git as the SCM. One thing that I need to do is review the list of "known issues" with the Git release being used. I have gone through the release notes and found that it only contains the fixes and enhancements in a particular release of Git, it does not contain a list of known issues/errata in a particular release. The github project also does not include the bug tracking list, so I am not able to figure out a way to review the known issues for a particular release. I considered reviewing the fixes in releases beyond the release used, but that has 2 problems. One, it doesn't contain any issues that are yet to be fixed. Two, only the fixes in the "next" release are truly relevant because fixes after that could have been introduced in a release after the release being used. An additional note is that the Git for Windows project does provide a list of known issues in the install
> 
> Could someone in this mailing list assist me in finding the known issues for a particular version?

It sounds like what you're asking is for a bug tracker that lists all
known issues. Git doesn't have one of those; we instead use the mailing
list for reporting issues. We've considered using a bug tracker in the
past, but the idea hasn't caught on yet.

The GitHub project is a mirror; it isn't the canonical resource, and the
Git project doesn't use it for issues or pull requests. Both of these
are also the same policy as for the Linux kernel[0], which you may or
may not use.

If you're looking for an easy way to check off a compliance box, you may
need to work with your management and/or auditors to see what approach
you use for other software (such as Linux) that has nontraditional bug
reporting practices. If you typically use a Linux distro that addresses
this issue for you, then you'll probably want to use Git from that
source as well.

Alternatively, you can use Git for Windows on a non-Windows system; it
should compile and run just fine on Linux, macOS, and Windows, although
it tends to carry more patches than Git itself.

[0] Yes, kernel.org has a bug tracker, but it is known to be incomplete
and many issues are raised only on the various mailing lists.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

RE: EXTERNAL: Re: List of Known Issues for a particular release

[Mark T. Ortell]

Elijah,

Thanks for the response. I am not clear whether the test_expect_failure means that the test is trying to do something that should fail and so it is a valid test case or if it is a test case that is failing, but should succeed and has only been temporarily disabled until it is fixed. I'm guessing the former. In this case, if it successfully did whatever it were testing, that would be an issue. A simple example of this would be a test to try to login with an invalid username and password. That is expected to fail and if it passed, it would be an issue. If this is the case, then it doesn't look like it provides a list of issues. Please clarify what the test_expect_failure indicates. 

Below is the output from the provided command:
t/t0050-filesystem.sh:test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
t/t1021-rerere-in-workdir.sh:test_expect_failure SYMLINKS 'rerere in workdir (relative)' '
t/t1060-object-corruption.sh:test_expect_failure 'clone --local detects misnamed objects' '
t/t1309-early-config.sh:test_expect_failure 'ignore .git/ with invalid repository version' '
t/t1309-early-config.sh:test_expect_failure 'ignore .git/ with invalid config' '
t/t1410-reflog.sh:test_expect_failure 'reflog with non-commit entries displays all entries' '
t/t1430-bad-ref-name.sh:test_expect_failure 'branch -m can rename from a bad ref name' '
t/t1430-bad-ref-name.sh:test_expect_failure C_LOCALE_OUTPUT 'push --mirror can delete badly named ref' '
t/t1512-rev-parse-disambiguation.sh:test_expect_failure 'two semi-ambiguous commit-ish' '
t/t1512-rev-parse-disambiguation.sh:test_expect_failure 'three semi-ambiguous tree-ish' '
t/t1512-rev-parse-disambiguation.sh:test_expect_failure 'parse describe name taking advantage of generation' '
t/t3030-merge-recursive.sh:test_expect_failure 'merge-recursive rename vs. rename/symlink' '
t/t3102-ls-tree-wildcards.sh:test_expect_failure 'ls-tree does not yet support negated pathspec' '
t/t3401-rebase-and-am-rename.sh:test_expect_failure 'rebase (am): directory rename detected' '
t/t3401-rebase-and-am-rename.sh:test_expect_failure 'am: directory rename detected' '
t/t3404-rebase-interactive.sh:test_expect_failure REBASE_P 'exchange two commits with -p' '
t/t3425-rebase-topology-merges.sh:test_expect_failure "rebase -p --root on non-linear history is a no-op" "
t/t3425-rebase-topology-merges.sh:test_expect_failure "rebase -p drops merge commit when entire first-parent side is dropped" "
t/t3427-rebase-subtree.sh:test_expect_failure REBASE_P \
t/t3427-rebase-subtree.sh:test_expect_failure REBASE_P \
t/t3427-rebase-subtree.sh:test_expect_failure REBASE_P \
t/t3427-rebase-subtree.sh:test_expect_failure REBASE_P \
t/t3427-rebase-subtree.sh:test_expect_failure REBASE_P \
t/t3427-rebase-subtree.sh:test_expect_failure 'Rebase -Xsubtree --onto commit 4' '
t/t3427-rebase-subtree.sh:test_expect_failure 'Rebase -Xsubtree --onto commit 5' '
t/t3427-rebase-subtree.sh:test_expect_failure 'Rebase -Xsubtree --onto empty commit' '
t/t3510-cherry-pick-sequence.sh:test_expect_failure '--signoff is automatically propagated to resolved conflict' '
t/t3510-cherry-pick-sequence.sh:test_expect_failure '--signoff dropped for implicit commit of resolution, multi-pick case' '
t/t3510-cherry-pick-sequence.sh:test_expect_failure 'sign-off needs to be reaffirmed after conflict resolution, single-pick case' '
t/t3600-rm.sh:test_expect_failure SYMLINKS 'rm across a symlinked leading path (w/ index)' '
t/t3701-add-interactive.sh:test_expect_failure 'split hunk "add -p (no, yes, edit)"' '
t/t3903-stash.sh:test_expect_failure 'stash directory to file' '
t/t3903-stash.sh:test_expect_failure 'stash file to directory' '
t/t3904-stash-patch.sh:test_expect_failure 'stash -p with split hunk' '
t/t3910-mac-os-precompose.sh:test_expect_failure 'handle existing decomposed filenames' '
t/t4014-format-patch.sh:test_expect_failure 'additional command line cc (rfc822)' '
t/t4014-format-patch.sh:test_expect_failure 'command line To: header (rfc822)' '
t/t4014-format-patch.sh:test_expect_failure 'command line To: header (rfc2047)' '
t/t4014-format-patch.sh:test_expect_failure 'configuration To: header (rfc822)' '
t/t4014-format-patch.sh:test_expect_failure 'configuration To: header (rfc2047)' '
t/t4038-diff-combined.sh:test_expect_failure 'combine diff coalesce three parents' '
t/t4205-log-pretty-formats.sh:test_expect_failure C_LOCALE_OUTPUT 'NUL termination with --stat' '
t/t5100-mailinfo.sh:test_expect_failure 'mailinfo -b trailing [PATCH]' '
t/t5100-mailinfo.sh:test_expect_failure 'mailinfo -b separated double [PATCH]' '
t/t5309-pack-delta-cycles.sh:test_expect_failure 'failover to an object in another pack' '
t/t5309-pack-delta-cycles.sh:test_expect_failure 'failover to a duplicate object in the same pack' '
t/t5512-ls-remote.sh:test_expect_failure 'ls-remote with filtered symref (--heads)' '
t/t5540-http-push-webdav.sh:test_expect_failure 'user was prompted only once for password' '
t/t5540-http-push-webdav.sh:test_expect_failure 'push to password-protected repository (no user in URL)' '
t/t5607-clone-bundle.sh:test_expect_failure 'bundle --stdin' '
t/t5607-clone-bundle.sh:test_expect_failure 'bundle --stdin <rev-list options>' '
t/t5610-clone-detached.sh:test_expect_failure 'cloned HEAD is detached' '
t/t5801-remote-helpers.sh:test_expect_failure 'pushing without marks' '
t/t6018-rev-list-glob.sh:test_expect_failure 'rev-parse accepts --glob as detached option' '
t/t6018-rev-list-glob.sh:test_expect_failure 'rev-parse is not confused by option-like glob' '
t/t6018-rev-list-glob.sh:test_expect_failure 'shortlog accepts --glob as detached option' '
t/t6018-rev-list-glob.sh:test_expect_failure 'shortlog --glob is not confused by option-like argument' '
t/t6023-merge-file.sh:test_expect_failure "merge without conflict (missing LF at EOF)" \
t/t6023-merge-file.sh:test_expect_failure "merge result added missing LF" \
t/t6035-merge-dir-to-symlink.sh:test_expect_failure 'do not lose untracked in merge (resolve)' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'merge of D2 & E4 merges a2s & reports conflict for a/file' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'detect rename/rename/add-source for virtual merge-base' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'check symlink modify/modify' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'check symlink add/add' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'check submodule modify/modify' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'check submodule add/add' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'check conflicting entry types (submodule vs symlink)' '
t/t6036-recursive-corner-cases.sh:test_expect_failure 'check conflicting modes for regular file' '
t/t6038-merge-text-auto.sh:test_expect_failure 'checkout -m after setting text=auto' '
t/t6038-merge-text-auto.sh:test_expect_failure 'checkout -m addition of text=auto' '
t/t6038-merge-text-auto.sh:test_expect_failure 'cherry-pick patch from after text=auto was added' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'rename/modify/add-source conflict resolvable' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'conflict caused if rename not detected' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'missed conflict if rename not detected' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'detect rename/add-source and preserve all data' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'detect rename/add-source and preserve all data, merge other way' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'detect conflict with rename/rename(1to2)/add-source merge' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'rename/rename/add-source still tracks new a file' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'rad-check: rename/add/delete conflict' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'rrdd-check: rename/rename(2to1)/delete/delete conflict' '
t/t6042-merge-rename-corner-cases.sh:test_expect_failure 'mod6-check: chains of rename/rename(1to2) and rename/rename(2to1)' '
t/t6043-merge-rename-directories.sh:test_expect_failure '9g-check: Renamed directory that only contained immediate subdirs, immediate subdirs renamed' '
t/t6043-merge-rename-directories.sh:test_expect_failure '10e-check: Does git complain about untracked file that is not really in the way?' '
t/t6046-merge-skip-unneeded-updates.sh:test_expect_failure '4a-check: Change on A, change on B subset of A, dirty mods present' '
t/t6102-rev-list-unexpected-objects.sh:test_expect_failure 'traverse unexpected non-blob entry (lone)' '
t/t6102-rev-list-unexpected-objects.sh:test_expect_failure 'traverse unexpected non-blob tag (lone)' '
t/t6120-describe.sh:test_expect_failure ULIMIT_STACK_SIZE 'name-rev works in a deep repo' '
t/t7006-pager.sh:test_expect_failure TTY 'pager runs from subdir' '
t/t7008-grep-binary.sh:test_expect_failure 'git grep .fi a' '
t/t7300-clean.sh:test_expect_failure 'nested (empty) bare repositories should be cleaned even when in .git' '
t/t7300-clean.sh:test_expect_failure 'nested (non-empty) bare repositories should be cleaned even when in .git' '
t/t7405-submodule-merge.sh:test_expect_failure 'file/submodule conflict' '
t/t7405-submodule-merge.sh:test_expect_failure 'directory/submodule conflict; keep submodule clean' '
t/t7405-submodule-merge.sh:test_expect_failure !FAIL_PREREQS 'directory/submodule conflict; should not treat submodule files as untracked or in the way' '
t/t7405-submodule-merge.sh:test_expect_failure 'directory/submodule conflict; merge --abort works afterward' '
t/t7410-submodule-checkout-to.sh:test_expect_failure 'can see submodule diffs just after checkout' '
t/t7504-commit-msg-hook.sh:test_expect_failure 'merge --continue remembers --no-verify' '
t/t9010-svn-fe.sh:test_expect_failure 'empty revision' '
t/t9010-svn-fe.sh:test_expect_failure 'timestamp and empty file' '
t/t9010-svn-fe.sh:test_expect_failure 'change file mode but keep old content' '
t/t9020-remote-svn.sh:test_expect_failure REMOTE_SVN 'the sha1 differ because the git-svn-id line in the commit msg contains the url' '
t/t9151-svn-mergeinfo.sh:test_expect_failure 'everything got merged in the end' '
t/t9350-fast-export.sh:test_expect_failure 'no exact-ref revisions included' '
t/t9400-git-cvsserver-server.sh:test_expect_failure "cvs update w/o -d doesn't create subdir (TODO)" '
t/t9601-cvsimport-vendor-branch.sh:test_expect_failure PERL 'check a file that was imported twice' '
t/t9602-cvsimport-branches-tags.sh:test_expect_failure PERL 'test branch B_FROM_INITIALS' '
t/t9602-cvsimport-branches-tags.sh:test_expect_failure PERL 'test branch B_FROM_INITIALS_BUT_ONE' '
t/t9602-cvsimport-branches-tags.sh:test_expect_failure PERL 'test branch B_MIXED' '
t/t9602-cvsimport-branches-tags.sh:test_expect_failure PERL 'test tag vendortag' '
t/t9602-cvsimport-branches-tags.sh:test_expect_failure PERL 'test tag T_ALL_INITIAL_FILES_BUT_ONE' '
t/t9602-cvsimport-branches-tags.sh:test_expect_failure PERL 'test tag T_MIXED' '
t/t9603-cvsimport-patchsets.sh:test_expect_failure PERL 'import with criss cross times on revisions' '
t/t9801-git-p4-branch.sh:test_expect_failure 'git p4 clone file subset branch' '
t/t9804-git-p4-label.sh:test_expect_failure 'two labels on the same changelist' '
t/t9809-git-p4-client-view.sh:test_expect_failure 'overlay collision 2 to 1' '
t/t9809-git-p4-client-view.sh:test_expect_failure 'overlay collision 1 to 2, but 2 deleted' '
t/t9809-git-p4-client-view.sh:test_expect_failure 'overlay collision 1 to 2, but 2 deleted, then 1 updated' '
t/t9809-git-p4-client-view.sh:test_expect_failure 'overlay sync swap: colA no content switch' '
t/t9809-git-p4-client-view.sh:test_expect_failure 'overlay sync swap: colB no change' '
t/t9810-git-p4-rcs.sh:test_expect_failure 'Add keywords in git which do not match the default p4 values' '
t/t9816-git-p4-locked.sh:test_expect_failure 'edit with lock taken' '
t/t9816-git-p4-locked.sh:test_expect_failure 'delete with lock taken' '
t/t9816-git-p4-locked.sh:test_expect_failure 'chmod with lock taken' '
t/t9816-git-p4-locked.sh:test_expect_failure 'move with lock taken' '
t/t9819-git-p4-case-folding.sh:test_expect_failure 'Clone lc repo using uc name' '
t/t9819-git-p4-case-folding.sh:test_expect_failure 'Clone UC repo with lc name' '
t/t9822-git-p4-path-encoding.sh:test_expect_failure 'Clone auto-detects depot with iso8859-1 paths' '
t/t9825-git-p4-handle-utf16-without-bom.sh:test_expect_failure 'clone depot with invalid UTF-16 file in non-verbose mode' '
t/t9902-completion.sh:test_expect_failure 'complete with tilde expansion' '
t/test-lib-functions.sh:test_expect_failure () {

Regards,
Mark


-----Original Message-----
From: Elijah Newren [mailto:newren@gmail.com] 
Sent: Thursday, July 11, 2019 11:00 AM
To: Mark T. Ortell <mtortell@ra.rockwell.com>
Cc: git@vger.kernel.org
Subject: EXTERNAL: Re: List of Known Issues for a particular release

[Use caution with links & attachments]



On Thu, Jul 11, 2019 at 8:50 AM Mark T. Ortell <mtortell@ra.rockwell.com> wrote:
>
> Hello,
>
> I am doing a software tool assessment for functional safety and I am 
> reviewing the use of Git as the SCM. One thing that I need to do is 
> review the list of "known issues" with the Git release being used. I 
> have gone through the release notes and found that it only contains 
> the fixes and enhancements in a particular release of Git, it does not 
> contain a list of known issues/errata in a particular release. The 
> github project also does not include the bug tracking list, so I am 
> not able to figure out a way to review the known issues for a 
> particular release. I considered reviewing the fixes in releases 
> beyond the release used, but that has 2 problems. One, it doesn't 
> contain any issues that are yet to be fixed. Two, only the fixes in 
> the "next" release are truly relevant because fixes after that could 
> have been introduced in a release after the release being used. An 
> additional note is that the Git for Windows project does provide a 
> list of known issues in the install
>
> Could someone in this mailing list assist me in finding the known issues for a particular version?
>
> Best Regards,
> Mark Ortell

Probably not in the format you want, and likely including noise that isn't relevant, but in a clone of git.git you could run:

git grep ^test_expect_failure t/

Re: EXTERNAL: Re: List of Known Issues for a particular release

[Elijah Newren]

Hi Mark,

On Thu, Jul 11, 2019 at 12:02 PM Mark T. Ortell
<mtortell@ra.rockwell.com> wrote:
>
> Elijah,
>
> Thanks for the response. I am not clear whether the test_expect_failure means that the test is trying to do something that should fail and so it is a valid test case or if it is a test case that is failing, but should succeed and has only been temporarily disabled until it is fixed. I'm guessing the former. In this case, if it successfully did whatever it were testing, that would be an issue. A simple example of this would be a test to try to login with an invalid username and password. That is expected to fail and if it passed, it would be an issue. If this is the case, then it doesn't look like it provides a list of issues. Please clarify what the test_expect_failure indicates.

Please don't top-post on this list.

test_expect_failure (as well as other helper functions in the test
harness library, such as test_expect_success, test_must_fail,
test_might_fail, etc.) are explained in t/README.  By its definition,
it technically satisfies "list of known issues" as you asked for.
However, most software products that publish a list of known issues
has probably curated problems that users are likely to see or be
curious about, and which they want to inform users of both to reduce
support load and help users avoid problems.

This list is not curated in any such way.  It's just a list of issues
developers thought to document for themselves and/or other developers.
It is thus way different than what you might want:

(1) There is evidence that some have used it for "In an ideal world,
this thing should support this feature too in which case I'd expect it
to behave a certain way that it doesn't yet."  The line between
feature (what works is fine but we could make it better) and bug (it's
not really correct if it doesn't do it this way) gets really blurry at
times, and you'd pick a much different tradeoff in communication
between developers than you would in communication from developers to
users; with other developers you spend a lot more time talking about
internals and goals and direction we'd like to move the software in.

(2) Also, some of these "known breakages" could be in corner cases
that are very unlikely to be hit be users, and perhaps not only likely
to be hit by individual users, but unlikely that anyone anywhere will
ever hit that error (some of the merge recursive tests I added might
fall into that category).

(3) There may also be cases where someone once thought that optimal
behavior would be a little different and that they were planning to
implement more features, and then later changed their mind but forgot
to clean up the testcases.

(4) ...and that's just a few off the top of my head.  I'm sure the
list has several other things that make it not quite match what you
want.

As such, Brian's answer to your question elsewhere in this thread is
probably better than mine, but if by chance you are just being forced
to go through a box checking exercise and there's no reason for
needing these results other than that someone asked that they be
provided (I sometimes had to go through such exercises when I worked
at Sandia National Labs years ago), then technically the command I
gave you could be used to satisfy it.

> Below is the output from the provided command:
<snip>

Not sure why you included this.

> Regards,
> Mark


Best Wishes,
Elijah

Re: List of Known Issues for a particular release

[Mark T. Ortell]

> test_expect_failure (as well as other helper functions in the test 
> harness library, such as test_expect_success, test_must_fail, 
> test_might_fail, etc.) are explained in t/README.  By its definition, 
> it technically satisfies "list of known issues" as you asked for.
> However, most software products that publish a list of known issues 
> has probably curated problems that users are likely to see or be 
> curious about, and which they want to inform users of both to reduce
>  support load and help users avoid problems.

Perfect, that answers my question. 

> This list is not curated in any such way.  It's just a list of issues 
> developers thought to document for themselves and/or other developers.
> It is thus way different than what you might want:
> 
> (1) There is evidence that some have used it for "In an ideal world, 
> this thing should support this feature too in which case I'd expect it 
> to behave a certain way that it doesn't yet."  The line between 
> feature (what works is fine but we could make it better) and bug (it's 
> not really correct if it doesn't do it this way) gets really blurry at 
> times, and you'd pick a much different tradeoff in communication 
> between developers than you would in communication from developers to 
> users; with other developers you spend a lot more time talking about 
> internals and goals and direction we'd like to move the software in.
> 
> (2) Also, some of these "known breakages" could be in corner cases 
> that are very unlikely to be hit be users, and perhaps not only likely 
> to be hit by individual users, but unlikely that anyone anywhere will 
> ever hit that error (some of the merge recursive tests I added might 
> fall into that category).
> 
> (3) There may also be cases where someone once thought that optimal 
> behavior would be a little different and that they were planning to 
> implement more features, and then later changed their mind but forgot 
> to clean up the testcases.
> 
> (4) ...and that's just a few off the top of my head.  I'm sure the 
> list has several other things that make it not quite match what you 
> want.

Thanks for the detailed clarification. This helps a lot. It may require a
bit of manual work sifting through these to see which could potentially
affect our use cases (very very unlikely any will, but that’s the due diligence
that is required for functional safety).

> As such, Brian's answer to your question elsewhere in this thread is 
> probably better than mine, but if by chance you are just being forced 
> to go through a box checking exercise and there's no reason for 
> needing these results other than that someone asked that they be 
> provided (I sometimes had to go through such exercises when I worked 
> at Sandia National Labs years ago), then technically the command I 
> gave you could be used to satisfy it.

Thanks Brian for your thoughts. We don't use much open source software
for our functional safety development (for this reason), so this is new 
territory for us. I think Elijah's information will get me most of the way there.

Also, I pulled down the source for the release version we are using and ran 
the test suite on it to have results that confirm that the software is working 
according to the design, so that is really helpful to have as well. 

Cheers,
Mark