[developers] consolidating LKB and [incr tsdb()] versions

[Stephan Oepen]

hi again, john (and all):

ann and emily, please read on.

> in terms of internal DELPH-IN responsibilities, the current LKB trunk used to be packaged via what we call the LinGO builds (http://lingo.delph-in.net) and the Ubuntu+LKB live CD (https://wiki.ling.washington.edu/bin/view.cgi/Main/KnoppixLKB).  both are maintained by UW, so i am not quite sure about the breadth of their user base?  but i am wondering whether these UW builds could move to using the FOS code in the foreseeable future (seeing as i am proposing to officially call an end ?

i sent the above (incomplete) message somewhat hastily during the
summit, so that folks in the LKB (FOS) tutorial could look at it then
and there.

in the meantime, john and i have started consolidating the FOS and the
LOGON branches of the LKB and [incr tsdb()] code bases.  we hope to
have a unified version available in a week or two, which would mean
that LKB and [incr tsdb()] functionality will again be more closely
synchronized across the two branches (some functionality will only
remain available in the LOGON environment, though, e.g. due to
dependencies on external, linux-only binaries).

we would like to propose that this new, actively developed version of
the LKB and [incr tsdb()] become the 'trunk' in the DELPH-IN
SubVersioN repository sometime in late august.  the current 'trunk'
(where there has not been active development for the past few years)
would then be preserved as a tag (or possibly a branch, if there was
an expectation of future revisions).  at that point, the LinGO builds
and Ubuntu+LKB creation (both maintained at UW) would likely need some
attention, to either work off the new tag or adapt the build
environment to the new version.

once the consolidation is complete, i would be tempted to spring-clean
the LKB and [incr tsdb()] code bases, seeking to remove 'dead' code,
for example sub-modules that have been superseded by newer
developments or have long fallen out of use and are not actively
maintained.  the following candidates for removal come to my mind (but
there are likely more):

src/glue/sppp.lsp (precursor to REPP; oe)
src/main/ltemplates.lsp (unused since mid-1990s; oe)
src/mrs/spell.lisp (ERG-specific and long unused; ann)
src/mrs/mrsmunge.lisp (superseded by transfer rules; ann)
src/mt/fragments.lisp (oe)
src/mt/smt.lisp (oe)
src/preprocess/ (SPPP reimplementation, SAF, SMAF; ben)

i imagine john and i should take a joint pass and compile a more
definite list of candidates for code cleaning for review.  in the list
above, i have tried to indicate who i believe was the original code
owner.  ann, hoping you have read this far: would you be okay with
some purging of long unused code?  everyone else, if you suspect you
might be using any of the above sub-modules, please get in touch with
john and me!

best wishes, oe