I agree that to be coherent, we shall define in the glossarydefs.csv which entry is an acronym and which is a glossary definition.
The unused fields in the CSV file Documentation Tags could be used for that purpose, or a new field could be added. The number of entries to characterize should not be a big deal, I can do it. Maintaining the information should also not be a problem since each change needs to be reviewed. Of course, the logic in generateAcronyms.py would need a few bigger changes.
Producing automatically a large number of test documents including glossary definitions looks repetitive, unnecessary and just makes the documents bigger. Definitions are already available in the applicable documents.
Having a compact list of abbreviations fits better the scope of the test specifications and test plans and reports.
Maybe, as you suggest, I should update the issues, asking to include instead, an Abbreviations table at the end of the document, where abbreviation are strings defined as follows:
- contain only upper case characters, numbers and "/"s
- starting with an upper case character or a number
- can't be composed only by numbers
Note also that, as per https://github.com/lsst/lsst-texmf/blob/master/bin/generateAcronyms.py#L352, I am just reusing (and improving, in master uses only upper cases characters) the definition of acronym-like strings, made originally in the script. If this is not a valid definition anymore, the script should be reviewed.