Re: [gnugo-devel] unused code

[bump]

> However, it also comes with the down-side of making maintenance more
> difficult, and making it a little more difficult to read through the
> code. (I wonder how many people start looking at life.c when they want
> to start understanding GNU Go's life and death reading.)
>
> To reduce this penalty somewhat, I'd suggest:
> 1. (obvious) keeping the default-off code as separate as possible
> 2. When it would be a burden to accustom a patch to some code
> that hasn't been maintained for a while, the patch can simply break it.
> This is probably better sorted out once someone picks up working on
> that code.
>
> And if we agree that some code is obsolete and unlikely to be re-used
> again, I think we shouldn't hesitate actually removing it. We can keep
> the patches on the web in case someone wants to restart using them.

Of this unused code, I think life.c is fairly dead.  Debugboard
is said to be currently broke and I think Evan found that the
experimental reading code does not compile.

On the other hand, there are items in this list that I do not 
consider dead code.

We want to come back to semeai, and the experimental semeai has
a positive regression delta. The status of this is similar to
that of the connection code until recently.

Also I'm working on surround.c right now, and will submit a patch
adding some patterns that use it and a new move reason if I can
get it working well.

Maybe the right approach is for someone to take maintainer's
responsibility for any code that is not implemented by default,
and if no-one is willing to do so we might entertain patches to
remove it from the engine.

I will take responsibility for surround.c, semeai.c and oracle.c.

Dan