2009/7/14 Tim Jenness <[log in to unmask]>:
> On Jul 13, 2009, at 4:02 PM, Malcolm J. Currie wrote:
>
>>>> KPG1_TRBO
>>>> Regarding the error message difference, the CCDPACK code is the same as
>>>> my 1995 vintage code. I later corrected the KAPLIBS code.
>>>> As to the extra initialisations, it looks like one of those compiler
>>>> optimisation warnings or valgrind type changes. I'm not convinced that it's
>>>> needed, since the the Kth value is assigned using the K-1th, where K starts
>>>> from 2.
>>
>>> Ok. It's been left out.
>>
>> This does go to show it's worth adding a few extra comments to the commit
>> logs to understand the rationale or purpose of a change.
>>
>
> 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.
>
>> Unless somebody finds the original correspondence or a reason for the
>> extra lines...
>>
>>> sure. But I did not want to just delete the bug fix. If the routine is
>>> not used it should be deleted from KAPLIBS too. I think the problem is that
>>> we
>>
>> It's still used via TRANSFORMER in KAPRH. I still have legacy TRN files.
>>
>
> Which reminds me. Is KAPRH deprecated or not? :-)
>
> Should we be shipping it? Should it just be moved into
> applications/obsolete? Can we announce that it will no longer be shipped
> after nanahope (along with NBS). Would we be better off writing a small
> program that will convert the TRN files to AST than keeping kaprh and all
> the other code around?
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.
2) Keep software until the user-base falls below some critical number
- but we have no way of knowing how many people use a particular bit
of software.
3) Drop something as soon as it is deemed to be obsolete
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?
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.
David
|