Tim Jenness wrote:
> Yes. I would tend to opt for:
> 
>  - get a CSV dump of the existing database
> 
>  - merge any missing bits into docs_lis
> 
>  - tidy up info to remove all the useless stuff.
> 
>  - remove buildsupport/database
> 
> This will at least keep the document list in one place in CVS and retain 
> docfind.
> 
> Tim
> 
> On Sun, 2 Jul 2006, Norman Gray wrote:
> 
>> On 2006 Jul 1 , at 01.52, Malcolm J. Currie wrote:
>>
>>>>    java/source/topcat/src/docs/sun253.xml
>>>>    java/source/ttools/src/docs/sun256.xml
>>>
>>> When David said that he'd used SUN/256 for ATL my first thought it had
>>> been allocated already.  Apologies that I didn't do a locate for
>>> sun256 instead of sun256.tex.  That finds the STILTS manual.  SUN/257
>>> looks free.
>>
>> We've been here before, I think.  Jiscmail searches for "sun/256" and 
>> "docs_lis" provide groundhog reading.
>>
>>> Now we don't have a Software Librarian we should keep a master list of
>>> the documents in CVS, where all new documents or reserved numbers are
>>> maintained.  Then we consult this whenever we need a new number.  Looks
>>> like I'm volunteering.  It would be worth recording the original titles
>>> of reused SUN numbers too.
>>
>> For what it's worth, I've just updated etc/info/docs_lis with an entry 
>> for my SUN/248, plus entries for SUNs 247 and 249, which I found 
>> evidence for in docs/sun.  That file still shows SUN/256 as being ATL....
>>
>> The files etc/info/* have something of the grave about them.  They 
>> smell obsolete and useless.
>>
>> Now that they're safely in CVS, and thus preserved for posterity, it 
>> might be a good idea to clear some of these files out.  How about 
>> these suggested dispositions?
>>
>> INFO_CONDITIONS
>>   Now obsolete, except for historical interest.  I recall there's 
>> still text _somewhere_ which refers to the GPL, the old conditions, 
>> and FIGARO.  There might therefore be a case for keeping this and 
>> editing that text to refer to the CVS.  If it's not to be discarded, 
>> then editing the file to indicate that this is for historical 
>> reference only might be useful.
>>   Delete or edit.
>>
>> Makefile.am
>>   Doesn't appear to do anything terribly useful, other than install 
>> largely useless files (see below) in stardocs.
>>   Keep as a placeholder
>>
>> analysis_lis
>>   A sort-of index for the document set, which probably isn't 
>> comprehensive enough to be useful, and in any case was generated from 
>> the (no longer existing) Database, and so will become increasingly out 
>> of date.
>>   Delete
>>
>> appform.ps
>>   Application form for a username on a starlink node, to be filled in 
>> and passed to your local starlink manager.  It's been a loooong while...
>>   Delete
>>
>> bootstrap
>> component.xml
>> component.xml.in
>> configure.ac
>>   Build system.
>>   Keep as placeholders
>>
>> docs_lis
>>   The list of documents.  Still useful.  Not in a particularly useful 
>> format, but it's not clear that the effort of reorganising it (for 
>> example, splitting it into multiple SC,  SG, SGP, ... XML files, and 
>> reprocessing it into something like the other ones at 
>> cvs.starlink.ac.uk/~nxg) would be worth it in terms of payoff.
>>   Maintain as it is
>>
>> mud_lis
>>   ``This is an index of miscellaneous documents which are held at RAL for
>> the Starlink project.''  I doubt this is any longer true.
>>   Delete
>>
>> news
>>   I'm not sure what the contents of this file is telling me.  In any 
>> case, Starlink news is no more (surely!), and this file notes that it 
>> was generated from the no-long-existing Database
>>   Delete
>>
>> package-info.csv
>>   Search Jiscmail for discussion of this file.  I think its contents 
>> are redundant with the contents of the component.xml files (and the 
>> summary at cvs.starlink.ac.uk/~nxg), so that its continued existence 
>> is therefore confusing, even if it were being maintained.
>>   Delete
>>
>> ssi
>>   ``This is the master index of what is considered to be in the 
>> Starlink Software
>> Collection.''  This looks like it's full of information, but since 
>> it's probably not being maintained, and since many of its scrupulous 
>> categories are no longer meaningful (`no port planned', `Software 
>> distribution not done by RAL'), and since it's simply wrong in places 
>> (sources being located under /star/sources/*), it's probably not 
>> terribly useful in fact.  It mentions the detailed contents of the 219 
>> USSC releases, but that presumably won't be added to, since the 
>> releases are what's tagged in the repository, so even this isn't any 
>> longer useful.  It can remain of historical interest while sitting in 
>> the Attic, I'd imagine.
>>   Delete
>>
>> subject_lis
>>   Like analysis_lis, a marginally useful index, but again generated, 
>> and so not maintained.
>>   Delete
>>
>> support
>>   Redundant with component.xml.  And not maintained.  And even if it 
>> were, the support categories are now pretty fanciful.
>>   Delete
>>
>>
>>
>> I can't help feeling that it would be useful to take a similar broom 
>> to buildsupport/database, though I can't imagine that there's much 
>> that's still useful here.  Moving it in the repository from 
>> buildsupport/database to etc/database might be a start.
>>
>> Norman
>>
>>
>>
> 
Slight problem, you can only dump HTML or SQL (postgresql compatible) no 
CSV! Hence the HTML tables. But they are just simple HTML tables, so 
maybe TOPCAT can read and convert them!!

Steve.