Gerrit Pape wrote:
> Yes, I won't apply this patch.

Attached is a patch which attempts to stick to the items we agreed on.


======================================================================
Everywhere below here I'm strictly debating philosophy: You're the 
maintainer; you win these discussions by default, and I'm not about to 
start my own fork. Feel free to ignore all of it if you prefer.
======================================================================


> The plan was to adapt runsv.c to put additional information into the
> supervise/status file, and sv.c to display this information through
> additional command line switches.  These two files only need to be
> changed.

Agreed that no other files need to be changed to implement the new 
functionality. The other files needed to be changed so I could 
understand what I was doing. Backporting my completed patch to your 
coding style, on the other hand, was not particularly difficult.

> On Mon, Aug 29, 2005 at 08:12:39AM +0000, Gerrit Pape wrote:
> 
>>To query this information, I would prefer to extend the sv program, not
>>runsvstat.  runsvctrl, runsvstat, svwaitdown, svwaitup, most probably
>>will get obsolete some time, as the functionality is integrated into
>>sv.

I'm aware that you expressed that preference, and was aware of it at the 
time when I decided to go the route that I did. Indeed, I interpreted 
your preference as being related to the amount of work and/or effort 
involved in maintaining the old programs -- but if almost all of their 
code is shared with the new programs, then maintaining them involves far 
less workload than if they include their own implementations of 
everything down to PID maintenance.

> There's no point in sharing code in runsvstat & co and sv.

I disagree.

Duplicate code is always bad. It means that two different routines which 
are intended to do the same things may have different bugs which come to 
be fixed in one but not the other. It means that user expectations that 
functionality accessed one way will have similar behaviour to the same 
functionality accessed via a similar subcommand in the same package may 
be broken. It makes maintenance harder (as changes which impact said 
code need to be made in multiple places). It makes the code more verbose 
(as tasks which could be hidden away in a library and implemented only a 
single time, such as decoding PIDs, are instead implemented a number of 
different times in a number of different files).

It's just Bad Juju.

> There's also
> no point is changing the library code as contribution, which is taken
> literally from the daemontools and djbdns packages, out of the public
> domain.  Most of the library code is pretty well documented
>  http://cr.yp.to/software.html

I'm happy to keep my modified versions of code origionally in the public 
domain in the public domain as well.