>> Yes. It's difficult when it becomes a null commit (ie no change) but I
>> imagine I could have put something in the deletion commit.
Yes it would be handy, if in a decade's time somebody else wants to know
why some module was removed.
> Do we have a policy on obsolete software? I'm not aware of one.
> Options would seem to include:
>
> 1) Keep all software for ever - just in case someone is still using it.
We have removed files from the CVS days. They'll still accessible in
the repository, but not part of the released code. My tendency is an
unhelpful mix of 1) and 3) depending on the circumstances. 3) applies
more to the duplicated code. 1) to stuff that doesn't have an immediate
replacement and migh still being used. I could imagine for example,
people using the TRN files and TRANSFORMER because "AST is too hard" or
they're overwhelmed by the AST manual.
> All of them have obvious problems. I'd suggest keeping things until
> their retention becomes a serious problem. I don't thing KAPRH has
> become a serious problem has it?
No. Some of us still use it occasionally.
> BTW - in principle KAPLIBS should not contain anything that is used
> only by KAPRH. When I created KAPLIBS, I endevoured to move all
> KAPRH-only infrastructure into KAPRH rather than KAPLIBS.
There are some olde routines (without the KPG1_ prefix) that should be
retired too. I think the documentation---here SUN/238---should list
removed routines and present recommended replacements, just we did
in the NAG to PDA exercise.
Malcolm
|