I have gotten the feeling that there is no
   functioning back-channel for contributing stuff.

I think you're just being impatient.  That nobody has gotten around to
looking at your code certainly doesn't imply in *any* way that they
are slighting you.

You have to understand that everyone has a priority queue.  Many of
the things you mentioned are pretty low-priority items, and are likely
to not be dealt with for a while.

   I wrote PT_SYSCALL stuff for the SPARC and posted it to current-users
   _and_ sent it directly to deraadt...

I was under the impression that Theo was looking at this.  (At least,
comments he made seemed to indicate that he was.)  If he dropped it on
the floor, then *you* need to take the initiative to see that someone
else gets to it.  If you had sent it with send-pr, then it would show
up when I type `query-pr -x -q' on sun-lamp; since you didn't, I had
completely swapped it out and probably never would have thought of it
again.

Perhaps you expect us to be more diligent in recording things like
this so that we don't forget them.  It costs companies a HELL OF A LOT
of time and money to do so.  As this is a volunteer effort, we put the
responsibility for that on the user, but we also give them an easy
tool to use to make such records.

If you don't use send-pr, then a certain percentage of your reports
are simply going to be forgotten.  That's just too bad.  If you do use
it, then they will eventually get dealt with, based on their real
priority and how many other things there are to deal with.

   I've also noticed that my patch to gcc for -Wformat versus %qd was only
   partially applied (or perhaps was not actually applied, but recreated
   by someone else basd on my patch); [...]

None of the above.  I had implemented it in the -current tree before
you ever sent a patch for it.  Your PR is still open because I was
planning to add the warning code eventually.

   I wrote a replacement libcrypt that does reasonably secure password
   hashing in an exportable manner, and that's compatible with old hashed
   passwords if you have DES-based hashing code available to boot.  I
   posted about its availability (may even have posted the code, I'd have
   to check archives to be sure) to current-users and heard nary a peep of
   interest.

Perhaps the lack of interest speaks for itself; I don't see people
beating down my door for a new crypt(3) function.  Or, more likely,
perhaps nobody has gotten to it yet.

   I added tickadj to /kern.  Someone (cgd, I think) said it belonged in
   sysctl, which I can sort of understand, but can't understand why that
   would be cause to be uninterested in having it in kernfs.

1) I already put it in sysctl, but I explicitly did *not* make it
writable.  2) I agree with cgd that it would be a mistake to put it in
kernfs.  It is not the job of kernfs to export every kernel variable.
(It could be argued that kernfs shouldn't even exist.  Except for
/kern/msgbuf and /kern/rootdev, which are of pretty limited
usefulness, everything in it can be acquired by sysctl(2).)

To put it another way: We disagreed with you.  Deal.

   [Rest omitted because I think Chris's reply was adequate.]