Re: lynx-dev Dead code tactics: call for comments

[Bela Lubkin]

John Bley wrote:

> Here are five tactics for dealing with the dead code in lynx (which I'd 
> estimate at about 3%).  For each one, of course, I'm omitting the obvious 
> "except for code that somebody has plans to use/update in the immediate 
> future" clause.
> 
> 1) "Complete removal."  Remove dead files such as HTAAServ.c, cut the lines 
>    between #if 0 and company, etc.  This means that some elements of 
>    "history" might get lost, since lynx doesn't have a publicly-readable
>    cvs server or something similar.
>    PRO: smaller code base, smaller distribution, smaller binary, etc.
>    CON: "History loss" unless a source control system is implemented

This gets my vote.

We have a source control system.  It's at a grosser level than you're
used to, but it does exist.  We have archived old releases of source;
for instance,

  http://www.slcc.edu/lynx/release2-8-1/lynx2-8-1.tar.bz2
  http://www.slcc.edu/lynx/release2-8/lynx2-8.tar.gz
  http://www.slcc.edu/lynx/release2-7-2/lynx2-7-2.zip

These archives will exist "forever", somewhere on the net.  So whether
or not we move to a more formal and more granular source control system,
we won't lose old source.

> Personally, I think that the only proper, long-term strategy is to 
> adopt a source control mechanism so that the project history can be 
> examined, and then to use (1).  But I recognize that I'm only one 
> developer, and that changing the development process affects every 
> developer as well as making the maintainer's task harder in the short term.

Actually, the source is already under CVS.  The CVS tree just isn't
publically available.

> Of course, there's also the easiest solution of all,
> 
> 5) "Nop."  Do nothing.  Who cares about a few K of binary or tarball?
>    PRO: Easy.
>    CON: The binary and tar file keep growing.

There's a fallacy here.  The binary & tar file keep growing anyway,
regardless of what you do.  You only propose to shrink them slightly
before continuing.  What you mean is:

     CON: We don't lower the bar slightly, before continuing to grow the
          source and binary as we add new features in the future.

>Bela<