GNU bug report logs - #20714
tap-driver.sh outputs incorrect .trs tag

Previous Next

To reply to this bug, email your comments to 20714 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Arthur Schwarz" <aschwarz1309 <at> att.net>
To: <bug-automake <at> gnu.org>
Subject: tap-driver.sh outputs incorrect .trs tag
Date: Mon, 1 Jun 2015 14:17:19 -0700

[Message part 1 (text/plain, inline)]

The .trs tag :global-test-result: should be :test-global-result:.


15.3.3.2 Log files generation and test results recording
:test-global-result:
    This is used to declare the "global result" of the script. Currently,
the value of this field is needed only to be reported (more or less
verbatim) in the generated global log file $(TEST_SUITE_LOG), so it's quite
free-form. For example, a test script which run 10 test cases, 6 of which
pass and 4 of which are skipped, could reasonably have a PASS/SKIP value for
this field, while a test script which run 19 successful tests and one failed
test could have an ALMOST PASSED value. What happens when two or more
:test-global-result: fields are present in the same .trs file is undefined
behaviour.

XPASS: test2.tap 1
XFAIL: test2.tap 2
make[4]: Entering directory 
===============================
Testsuite summary for test 0.5
===============================
# TOTAL: 2
# PASS:  0
# SKIP:  0
# XFAIL: 1
# FAIL:  0
# XPASS: 1
# ERROR: 0
===========================
See src/test-suite.log
===========================

======= .trf =======
:global-test-result: FAIL
:recheck: yes
:copy-in-global-log: yes
:test-result: XPASS
:test-result: XFAIL



The failure of the past is the challenge of the present and the success of
the future.

[Makefile.am (application/octet-stream, attachment)]

Message #8 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Arthur Schwarz <aschwarz1309 <at> att.net>
Cc: 20714 <at> debbugs.gnu.org
Subject: Re: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 2 Jun 2015 10:47:28 -0400

On 2015-06-01 14:17 -0700, Arthur Schwarz wrote:
> The .trs tag :global-test-result: should be :test-global-result:.
> 
> 15.3.3.2 Log files generation and test results recording
> :test-global-result:
[...]
> ======= .trf =======
> :global-test-result: FAIL

Indeed, this is an error in the manual and it should be changed to
match Automake's actual behaviour.  Care to send a patch to that effect?

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Message #11 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: "Arthur Schwarz" <aschwarz1309 <at> att.net>
To: "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: RE: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 2 Jun 2015 09:24:19 -0700

A coupla' issues. I don't know Texinfo. I have included an extensive
revision of the TAP testing cycle as a pdf file, downloaded from an Open
Office Document. And, the only reason that I started rewriting the test
section was that I couldn't understand what was written and thought that if
I had to spend time understanding the Automake Manual I might as well do it
productively. I have finished a rough draft of everything in the test
section up to Dejagnu, and a description of the Parallel Test Harness
requirements for test cases and, of course, completing the introduction to
the TAP section I sent you. 

At this point the question is whether you would like to contribute to my
effort. Are you willing to proof my document and offer a critique and
suggestions? It would cut down on my time if I had a clear understanding of
Dejagnu, but lacking support, I will 'read the manual' and then test the
product.

As stated in 20715 <at> debbugs.gnu.org, the document is GPL's and the FSF owns
the copyright.

Oh, the point of the bug is that the operational software outputs an
incorrect .trf metadata tag. As to "what I plan to do to benefit humanity
and the Automake community", I will be rewriting the tap-driver.sh program
to conform to the TAP requirements in the TAP Standard. Although you have
dismissively answered my question on gawk by pointing out it is a POSIX
standard and that, by inference, I should read the manual, I believe that I
can persevere with this judicious comment in hand. I think I would have just
answered the question and then pointed out the source, but then, that's me. 

art

-----Original Message-----
From: Nick Bowler [mailto:nbowler <at> elliptictech.com] 
Sent: Tuesday, June 02, 2015 7:47 AM
To: Arthur Schwarz
Cc: 20714 <at> debbugs.gnu.org
Subject: Re: bug#20714: tap-driver.sh outputs incorrect .trs tag

On 2015-06-01 14:17 -0700, Arthur Schwarz wrote:
> The .trs tag :global-test-result: should be :test-global-result:.
> 
> 15.3.3.2 Log files generation and test results recording
> :test-global-result:
[...]
> ======= .trf =======
> :global-test-result: FAIL

   Indeed, this is an error in the manual and it should be changed to
   match Automake's actual behaviour.  Care to send a patch to that effect?

I forget, are you saying that the output of the tap-driver.sh program is
correct and the manual is wrong or are you saying that the tap-driver.sh
program is incorrect and the manual is right? I don't have time right now to
check to see what non-TAP programs output in their .trf files.

art

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Message #14 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Arthur Schwarz <aschwarz1309 <at> att.net>,
 "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: Re: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 02 Jun 2015 11:17:15 -0600

[Message part 1 (text/plain, inline)]

On 06/02/2015 10:24 AM, Arthur Schwarz wrote:
> A coupla' issues. I don't know Texinfo. I have included an extensive
> revision of the TAP testing cycle as a pdf file, downloaded from an Open
> Office Document.

While that may work, it is tedious to maintainers.  We have to figure
out which text you added or removed, then find the same text in the
upstream texinfo file and make the same edits.  And being a pdf, it may
be hard to copy and paste the changed text, making it all that harder.
You might make it easier by using color highlights or strikethrough
notations to call attention to your edits, but it is still not as
trivial as just having those edits already made in patch form against
the original upstream texinfo file.

If you want your patches to go in, it really WILL be better for you to
figure out how to directly patch the texinfo file.  It's not that hard
to figure out - it is a plain text representation with fairly obvious
markup for the most common tasks.  And we are more than willing to help
you with markup questions or with proof-reading, if we can start from a
patch that gets us 90% of the way to a final version without having to
do lots of copy-and-paste gyrations.  But if you just dump a .pdf file
of "here's the final product" without actually patching the upstream
source file, it will probably just be ignored, because in that case,
you'd have done only 10% of the work instead of 90%.  Like it or not,
free software works on a meritocracy principle, where the patches that
get applied are the ones written by people persistent enough to make the
maintainer's life easy.

For comparison, we prefer that someone says: "here are the changes to
your .c file to fix a bug", rather than "here is a complete .c file that
includes bug fixes but you have to locate what changed" or even "here is
a new binary that was compiled from a fixed .c file, but you have to
reverse engineer the binary to figure out what the changes were".

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: "Arthur Schwarz" <aschwarz1309 <at> att.net>
To: "'Eric Blake'" <eblake <at> redhat.com>,
 "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: RE: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 2 Jun 2015 10:59:08 -0700

I appreciate your comments. The TAP pdf that I sent you is part of a larger
document. At the moment the document is 48 pages and is a complete
replacement for Section 15 up to dejaGnu which I haven't started yet. The
pdf was sent in lieu of the Open Office document, which is the genesis of
the pdf. Open Office offers several alternative output representations for a
document, to wit
o XML 1.0 Text Document (.sxw), 
o XML 1.0 Text Template (.stw), 
o Microsoft Word 87/2000/XP (.doc), 
o Microsoft Word 95 (.doc), 
o Microsoft Word 6.0 (.doc), 
o Rich Text Format (.rtf), 
o Text (.txt), 
o Text Encoded (.txt), 
o HTML Document (.html), 
o DocBook (.xml), 
o Microsoft Word 2003 XML (.xml), 
o Uniform Office Format 2 Text (.uot), 
o Unified Office Format Text (.uot).

The Open Office Document (.odt) is available.

If none of these formats are suitable then the document will be made
available for the community of users of Automake and Automake will not be a
participant. I've spent 5 months trying to understand Section 15 of the
Automake Manual, and during that time thought it best to rewrite it. The
Automake Manual as it stands is not significant and difficult to understand
without experimentation. My thoughts are that a document should be an
explanation of use rather than a result to be explored.

My document has tables and drawings. Something which seems missing from the
Automake Manual (and other Texinfo manuals). I have been told that there is
a mechanism to incorporate drawings and, perhaps, other objects into a
Texinfo document. But if the document is written with the same clarity as
Section 15 then my life is too short to understand and experiment with until
I 'Get it right'.

So, if the intent is to say that the maintainers are not in a position to
remove Section 15 and insert a new Section 15 then I think that we are in a
pickle. I am definitely not going to spend another 5 months providing
changes to an existing document, most particularly since there has been no
indication that the 'suggested' changes are acceptable.

Sorry.
art

-----Original Message-----
From: Eric Blake [mailto:eblake <at> redhat.com] 
Sent: Tuesday, June 02, 2015 10:17 AM
To: Arthur Schwarz; 'Nick Bowler'
Cc: 20714 <at> debbugs.gnu.org
Subject: Re: bug#20714: tap-driver.sh outputs incorrect .trs tag

On 06/02/2015 10:24 AM, Arthur Schwarz wrote:
> A coupla' issues. I don't know Texinfo. I have included an extensive
> revision of the TAP testing cycle as a pdf file, downloaded from an Open
> Office Document.

While that may work, it is tedious to maintainers.  We have to figure
out which text you added or removed, then find the same text in the
upstream texinfo file and make the same edits.  And being a pdf, it may
be hard to copy and paste the changed text, making it all that harder.
You might make it easier by using color highlights or strikethrough
notations to call attention to your edits, but it is still not as
trivial as just having those edits already made in patch form against
the original upstream texinfo file.

If you want your patches to go in, it really WILL be better for you to
figure out how to directly patch the texinfo file.  It's not that hard
to figure out - it is a plain text representation with fairly obvious
markup for the most common tasks.  And we are more than willing to help
you with markup questions or with proof-reading, if we can start from a
patch that gets us 90% of the way to a final version without having to
do lots of copy-and-paste gyrations.  But if you just dump a .pdf file
of "here's the final product" without actually patching the upstream
source file, it will probably just be ignored, because in that case,
you'd have done only 10% of the work instead of 90%.  Like it or not,
free software works on a meritocracy principle, where the patches that
get applied are the ones written by people persistent enough to make the
maintainer's life easy.

For comparison, we prefer that someone says: "here are the changes to
your .c file to fix a bug", rather than "here is a complete .c file that
includes bug fixes but you have to locate what changed" or even "here is
a new binary that was compiled from a fixed .c file, but you have to
reverse engineer the binary to figure out what the changes were".

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Message #20 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Arthur Schwarz <aschwarz1309 <at> att.net>,
 "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: Re: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 02 Jun 2015 13:14:38 -0600

[Message part 1 (text/plain, inline)]

On 06/02/2015 11:59 AM, Arthur Schwarz wrote:
> I appreciate your comments. The TAP pdf that I sent you is part of a larger
> document. At the moment the document is 48 pages and is a complete
> replacement for Section 15 up to dejaGnu which I haven't started yet. The
> pdf was sent in lieu of the Open Office document, which is the genesis of
> the pdf.

I haven't yet seen any pdf, so it's hard for me to state what you are
referring to.

> Open Office offers several alternative output representations for a
> document, to wit

Indeed.  But as always in open source, it is better to post your
original preferred editing form (OpenOffice .odt is a portable format,
well supported on GNU/Linux systems) than it is to post any derived
forms (whether that be .pdf, .rtf, or even non-free formats like .doc),
especially if the derived forms lose information or are harder to edit
than the original.  Still, someone would have to translate that work
from OpenOffice into .texinfo for incorporation with the rest of the
manual.  In particular, while .odt is a portable format, it is still a
binary format and occupies a lot of space in a .git repository and is
hard to diff between revisions without installing additional tools;
whereas a plain-text format like .texinfo occupies less space and can be
diff'd using the same tools as on source code.

By all means, post your work.  All I'm saying is that you can accelerate
the acceptance of your work by making it in a format that is easier to
incorporate.  We're not going to outright reject your work, just because
we can't drop it in.  And if your work is truly as amazing as you are
making it out to be, then someone else will step up and help in the
transformation efforts.

> My document has tables and drawings. Something which seems missing from the
> Automake Manual (and other Texinfo manuals). I have been told that there is
> a mechanism to incorporate drawings and, perhaps, other objects into a
> Texinfo document. But if the document is written with the same clarity as
> Section 15 then my life is too short to understand and experiment with until
> I 'Get it right'.

We'd be glad to help you learn how to incorporate figures into .texinfo.

It would also help to know what original source your drawings are in.
For example, .fig is better than most other formats, because it is an
all-text representation rather than a binary (of course, directly
editing a .fig is not trivial; it's best to open up a decent graphics
editor, make changes, and then save back as .fig); a .png is portable
but binary and not easily edited.  If you are making your figures
directly in OpenOffice (or LibreOffice these days, now that OpenOffice
is falling out of favor in open source communities), I'm not sure how
easy or hard it is to save them out into a more reusable format like .fig.

> 
> So, if the intent is to say that the maintainers are not in a position to
> remove Section 15 and insert a new Section 15 then I think that we are in a
> pickle. I am definitely not going to spend another 5 months providing
> changes to an existing document, most particularly since there has been no
> indication that the 'suggested' changes are acceptable.

Without even seeing the 'suggested' changes, it's hard to make any sort
of judgment call.

I'm not trying to discourage you - by all means, PLEASE continue to
contribute, and make the documentation better.  Free software is more
powerful because anyone can scratch their itch, and your itch is the
quality of documentation.  All I'm trying to do is to make you aware
that you can't expect overnight adoption of your new work, especially if
it is not yet in a format that will drop in place of the older text.

Also, I am not the automake maintainer, but I do have commit access, and
I am also aware that the official listed maintainer has been very
hard-pressed for time lately to make much of any response on list.  I do
not want to become the maintainer, but I can help shepherd patches in,
provided that they do not become a time sink on my end.  That means that
if I'm the one stuck transcribing .odt into .texinfo, it probably won't
happen, but lack of my time should not be construed as rejection of your
work.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #23 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: "Arthur Schwarz" <aschwarz1309 <at> att.net>
To: "'Eric Blake'" <eblake <at> redhat.com>,
 "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: RE: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 2 Jun 2015 13:05:08 -0700

[Message part 1 (text/plain, inline)]

> 
> On 06/02/2015 11:59 AM, Arthur Schwarz wrote:
> 
> I haven't yet seen any pdf, so it's hard for me to state what you are
> referring to.
 
 
    Both .pdf and .odt files are included in this post.
 
> In particular, while .odt is a portable format, it is still a
> binary format 
 
    I found out yesterday that .odt files are zipped files - not binary. If
you unzip the .odt file there are several ASCII files and directories. In
truth, I have absolutely no idea what they are - or mean. It appears that
the text is in content.xml, but I haven't verified this.
 
> All I'm saying is that you can accelerate
> the acceptance of your work by making it in a format that is easier to
> incorporate.  We're not going to outright reject your work, just because
> we can't drop it in.  And if your work is truly as amazing as you are
> making it out to be, then someone else will step up and help in the
> transformation efforts.

On the other hand you will consider my work with due diligence until it is
converted, and haphazardly if it is not. So the labor of conversion is
complete before the process of acceptance is begun. That is the rub. (See
comments below on my 'amazing work'.)

> 
> > My document has tables and drawings. Something which seems missing from 
> 
> We'd be glad to help you learn how to incorporate figures into .texinfo.

I've spent 5 months on a task which I didn't enjoy to produce a product of
little interest. My entire objective in this effort was to learn enough so
that I can run a test. What I think I produced was a product to teach others
to perform testing with less effort.

> 
> It would also help to know what original source your drawings are in.

The drawing were done within Open Office using the Open Office tools. The
term 'drawing' is to be taken in the context of the Open Office application
which allows users to create 'drawings'.


> > 
> > So, if the intent is to say that the maintainers are not in a position
to
> > remove Section 15 and insert a new Section 15 then I think that we are
in a
> > pickle. 
> 
> Without even seeing the 'suggested' changes, it's hard to make any sort
> of judgment call.

The partial document is included (for TAP). The 'full' document is available
if you want it, but it is incomplete and unproofed (maybe 'unproved' would
be a better way of phrasing this, umm?).

> 
> I'm not trying to discourage you - by all means, PLEASE continue to
> contribute, and make the documentation better.  Free software is more
> powerful because anyone can scratch their itch, and your itch is the
> quality of documentation.  All I'm trying to do is to make you aware
> that you can't expect overnight adoption of your new work, especially if
> it is not yet in a format that will drop in place of the older text.

Thank you for the kind words. Just to 'set the record straight', whatever
that means, I am not so ego driven as to think that my work of stupendous
art is either stupendous or art. What I would like to think is that I
present a different viewpoint to an (un)willing audience, (1) a structure
showing the architectural outlines of a document, and (2) content which
shows the explication of the structure. I expect that if the document has
any provenance it will be critiqued, and the critique should address
structure, accuracy and content. The structural component is developed to
enable a user to look at the table of contents to get a 'feel' for the
contents, and to lead a user to understand how the Automake implementation
is structured. That is, if B is included in A then the document section
number should be A.B, subordination supports implementation. This does not
exist in the current Section 15. As to accuracy, I've tried. Nick Bowler
continuously questions my assumptions and is continuously correct in his
interpretations - drat.

> 
> I do
> not want to become the maintainer, but I can help shepherd patches in,
> provided that they do not become a time sink on my end.  That means that
> if I'm the one stuck transcribing .odt into .texinfo, it probably won't
> happen, but lack of my time should not be construed as rejection of your
> work.

I appreciate your thoughts. I completely agree with the notion of a 'time
sink'.

art (who develops amazing documents - true until critiqued otherwise)

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
>

[TAP.pdf (application/pdf, attachment)]

[TAP.odt (application/vnd.oasis.opendocument.text, attachment)]

Message #26 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Arthur Schwarz <aschwarz1309 <at> att.net>,
 "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: Re: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 02 Jun 2015 14:33:22 -0600

[Message part 1 (text/plain, inline)]

On 06/02/2015 02:05 PM, Arthur Schwarz wrote:
>>
>> On 06/02/2015 11:59 AM, Arthur Schwarz wrote:
>>
>> I haven't yet seen any pdf, so it's hard for me to state what you are
>> referring to.
>  
>  
>     Both .pdf and .odt files are included in this post.

Uggh.  That resulted in your mail being 235k, times the bandwidth
required to send it to every subscriber of the list, which both taxes
the servers and makes downstream recipients behind rate-limited
connections (whether by slow speed or by pricey data plans) suffer.  As
a result, many GNU lists intentionally put a cap on email beyond 100k,
at which point a moderator has to manually let the mail through.  If you
cannot trim your content to smaller data, then it is often better to
merely post a URL to large files and let only the interested people
chase down that URL than to spam the list with the binary file.  And
since the .pdf is merely a derived file taking up the bulk of the size,
limiting your mail to just the 33k .odt would have been sufficient.  But
really, binary format data is SOOOO much of a bandwidth hog compared to
pasting plain text representations, particularly since the plain text
can be read inline instead of having to fire up a separate program.

>  
>> In particular, while .odt is a portable format, it is still a
>> binary format 
>  
>     I found out yesterday that .odt files are zipped files - not binary.

Just because it happens to be unzippable into a tree of ascii files does
not change the fact that .odt itself is a binary layout.  As soon as you
unzip it, it is no longer .odt, and also no longer a single file.  I
stand by my assertion that .odt is binary - you cannot do 'grep FOO
*.odt' to find all instances of FOO in the file (and while you CAN
download other utilities that transparently pull out the text from the
.odt in order to make grepping possible, it adds that much more bloat as
a prerequisite on a development machine, and the conversion to text is
lossy in that it loses your desired formatting).

Sadly, this is what I see when opening the .odt:

>  15.4.3.2.4  Test Anything Protocol (TAP) Test Driver
> The Test Anything Protocol (TAP) is a Error: Reference source not found. The protocol TAP Standard is defined at  http://testanything.org/ as modified by Automake. The TAP Test Driver is called a TAP Harness in the TAP Standard. YAML Standard (http://www.yaml.org/spec/1.2/spec.html)
> TAP requires an interfacing test class program to output ASCII lines as defined by the TAP Protocol. The TAP test driver analyses these lines and outputs a log file and Test Results File compatible with the Error: Reference source not found.

The broken links in the very first paragraph aren't helping the cause.

As a high level overview, I see that you have added several tables, but
no graphics, into this particular section.  Without actually spending
time reading it, I see nothing too particularly difficult to translate
back into .texinfo format, except maybe the "∑test lines" usage of a
sigma, but I suspect even that can be done.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #29 received at 20714 <at> debbugs.gnu.org (full text, mbox):

From: "Arthur Schwarz" <aschwarz1309 <at> att.net>
To: "'Eric Blake'" <eblake <at> redhat.com>,
 "'Nick Bowler'" <nbowler <at> elliptictech.com>
Cc: 20714 <at> debbugs.gnu.org
Subject: RE: bug#20714: tap-driver.sh outputs incorrect .trs tag
Date: Tue, 2 Jun 2015 14:20:44 -0700

Eric.

You know, I really appreciate your effort. I do. Now to the substance of it.

1. Now that I know the bandwidth limitations and constraints I will be much
more careful in transmitting files. I did not know before. I know now. I
will take care to determine what compression format to use prior to
transmission.

2. I stand by your stand by. If .odt is considered in its entirety then it
is a binary file (period, exclamation point). What would the preferred
transmittal format be, .odt/.pdf/other.

3. The first section paragraph is not done yet, sigh. I have wasted your
time. But I do stand by the unproofed remainder of the Section.

4. The broken links I am astonished at. I just tried both in Mozilla and
both lead to correct locations. I don't know how to fix this since it works
for me and not you. If you have any suggestions then I will pursue them.

5. There are other oddments in the Section since references to prior
Sections probably come out as undefined (or some such nonsense) in the
transmitted reading material. So, if you don't like 'broken links' you will
really not like these.

6. This is one section of many. In this section there are no 'pretty
pictures' In other sections there are. If you would like me to send the
complete document, I will - tell me what format you want (.odt/.pdf/other).
The caveat is that the first paragraph of this section needs rework and no
section following this section is proofed. What you get is an architectural
description of Automake testing, plus whatever whizbangs an agile mind can
create.

7. "\xAD\xF4test lines". I got tired of writing and to say that the cumulative
result of test line analysis is:  seems wordy for a title. But, this is a
little niggle not a major problem.

8. As a side note, I (think I) write well but I enjoy software development.
So the document is an aside to things that I truly enjoy.

art

PSst: You should look at the tables. The question I would ask is do they add
clarity?

There's no time like the present to forget the past.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.