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


-- 
------------------------------------------------------------------------ 
----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK