> Secondly, what often happens is that someone makes the effort to
> improve a piece of code, posts about it here, gets buried with emails
> on how it isn't perfect, should do X, Y, and oh, while it's at it, Z
> too. This is often followed by a discouraged developer, who decides
> to drop things altogether, and we're still stuck with the old code.

This sounds...familiar.

I did an implementation of PTRACE_SYSCALL, including the MD bits for
sparc and sun3.  It was not particularly clean and had numerous
problems of varying degrees of severity.  When I pinged about
committing it, these problems were pointed out to me, including a few I
wasn't already aware of.

As a result, PTRACE_SYSCALL is still sitting on a shelf.  I've been
meaning, ever since then, to get it cleaned up and committed.  Now I
probably never will, because NetBSD has decided that people like me
aren't worth supporting, so I am unlikely to do very much more for
NetBSD, including bothering to port PTRACE_SYSCALL to anything newer
than my personal source freeze point.

Now, this isn't necessarily a bad thing in this case.  My
implementation *wasn't* very clean and *did* have numerous defects; I
had and have no argument with any of the various claims that
such-and-such was a problem with what I'd written.

But it does mean that there still is no PTRACE_SYSCALL in the tree for
anyone to use as a base, to clean up, port to more architectures, etc.

Was preserving the cleanliness of the tree worth rejecting and thereby
losing the nascent implementation, in this case?  I don't know; we can
never know what would have happened.  I simply offer it as a specific
example that sounds a lot like what you're talking about here.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B