I am having a small disagreement with the author of "lsof" over distributing
my port of lsof 3.19 to NetBSD 1.0.  He has a problem because he is not
comfortable in distributing something he can't test himself, and he also
mentioned this:

------- Begin Included Message

[snip]

Yes, you can give me diffs, but I can't test them anywhere.  I
can't even see if the diffs break the 0.9a version that I know
worked.  I can't test any changes I make that might affect your
version.  I won't distribute code or binaries that I haven't
tested myself on the named dialects and their versions.

Another factor is the rate at which I'm currently producing lsof
revisions.  3.19, for example, is now out of date.  I completed
3.20 today and it has become the latest revision.  It fixes some
bugs and adds support for Linux 1.1.75 and up, IRIX 6.0, and V/88
R40V4.3.  It has the Sun Makefile change you suggested.  I tested
lsof on 20+ hosts this week, and I can't expect any outside tester
to be that responsive.

[snip]

Getting back to your anguish about my distributing your changes,
two solutions occur to me:

1.  You could maintain your changes yourself and distribute them
    however you wish.  I am willing to put a reference to your
    distribution in the 00* files that accompany my lsof distribution.

    I'm not sure I could always remember to let you know when I
    release a new revision, so you could play catch-up, but I am
    willing to try.

2.  You can give me an account on your machine so I can do testing
    there myself.  As a matter of course, I need Internet access to
    your machine and the ability to read /dev/kmem.

    I'm not sure I really want to do this, because I now have too
    many places to test new lsof versions.  However, this alternative
    is moot if you can't give me access, so let's start with this question.

------- End of Included Message

You'll notice a common thread here, which is what I wanted to bring up:

(1) Specifically, he's concerned that if he replaces his existing method
    for building the program that is known to work on 0.9a with mine,
    that it won't work.  I don't know of anyone still running 0.9a, but as
    he says, I don't have a way to back-test it, he doesn't either, so what
    to do?

(2) More generally, there's this thorny problem.  It's been stated, by core
    members & others, that the best policy w.r.t. software packages is to do
    the port and give your changes back to the authors so that they can fold
    them into the mainstream releases.  But I've begun to see several cases
    of more complicated software with oodles of ports contained therein (of
    which "lsof" is a fair example) where the author is very uncomfortable
    with taking changes that s/he cannot test themselves.  (Another one that
    comes to mind is "gated"; Jeff once asked us if he could have an account
    on our old IRIX 4.0.5H system 'way back as it was the only way he could
    test changes for that O/S.).  This can become problematic because some
    of these programs require /dev/kmem access.

I'm not sure what to do about this state of affairs.  The authors are pushing
on us to do what the core does not want; i.e., maintain private ports and
force people to go hunt them down.  The alternative is to have a system made
available to the author(s) to test the changes on.  I am not in a position to
do this for "lsof", because JPL doesn't tend to look too highly on people not
associated with the Lab logging on to our computers  (-:

Sigh.  So, what's a mother to do?  Any volunteers for "porting.NetBSD.ORG"?

	- Greg