Whoof.  I had no idea what I was starting.

This is a compiled response to most of the fallout I've received so
far; it's about 8.5K, and probably is not something you should take the
time to read now if you're in a hurry.  It can wait.

First, I think that now that I have the gripe out of my system, I can
be slightly more rational and agree with the couple of people who have
pointed out that egos or no egos, delays or no delays, NetBSD is a
pretty impressive and useful piece of work, and thank those
responsible.  Even if _none_ of the stuff I've sent out is adopted, 1.0
is a reasonable place to start evolving my own version, which to some
extent I will end up doing whatever system I use.  My airing of
problems here may give the impression that my opinion of NetBSD, or at
least of the people involved, is entirely bad; this is far from
correct.  I simply am not listing the points I like, because it would
take me all day to do so and nobody would want to wade through the
resulting monster mail message.

chris writes:

> I've spent the last two or so months getting the release out the
> door, then travelling way too much, then changing cities.  I'm just
> now getting to "important mail" that was sent to me at the _beginning
> of october_.

Might I recommend something like vacation?  That would perhaps cut down
on the yammering and let people know, without taking your time to do
it, that you're likely to get to the mail late.

>> [... itemized list of reasons I was ticked ...]
> [... itemized responses ...]

Mostly not calling for a response, but...

>> I added an option for modifying the NFS mount options used when
>> mounting the root when booting diskless.
> i didn't see this, either.  however, there's a way to do this as a
> kernel compile option,

There is?  I couldn't see any such anywere, so I created a kernel
config option for it.

> and it should be doable at mount -u time, as well.

mount -u is too late for the problem I was having; without the patch it
never even gets out of nfs_mountroot().

>> [... SPARC console terminal emulator ...]
> this is a port-specific thing.  a port's 'owner' is really the final
> arbiter of taste and fashion about stuff to go into that port.

So it's deraadt not liking it, or not liking me, or perhaps both.
*shrug*  I'm already in a position of maintaining a private patch tree.

> I can't see why you'd need to make this a kernel option, in any case.

_Need_ too, perhaps not.  I could do it in init, I suppose, but since
it's a SPARC-dependent thing it seems good to me to put it in a
conveniently SPARC-dependent place.

> (it seems to me that there are other ways to do it that are more
> appropriate.  adding kernel options to #ifdef 2 lines of code are
> hardly ever appropriate.)

Not to seem to be asking for more of your time now - my private patch
tree is eminently satisfactory at present - but I'd be interested to
hear your ideas.

mycroft (quotes and) writes:

>> 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.

Oh, I assure you, I don't feel singled out.  A few private notes I've
received and a couple more public ones have indicated I'm not alone in
my "feeling".  Perhaps it's nothing but a PR problem [that's
public-relations, not problem-report :-], but there's a problem of some
sort.

>> [... PT_SYSCALL ...]
> I was under the impression that Theo was looking at this.  ([...].)

Perhaps he is, or will be when he gets unbusy enough to pay attention
to NetBSD again (someone indicated he was busy with other things now).

> If he dropped it on the floor, then *you* need to take the initiative
> to see that someone else gets to it.

How can I _tell_ whether he's dropped it on the floor, as opposed to
just being slow about it?  Bother him with yet more mail? :-)

> 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.

Shall I?  I can supply known-working diffs relative to 1.0 or untested
diffs relative to last night's sup.  Or both.  Or should I just let
deraadt get around to it?

>> [... my patch to gcc for -Wformat versus %qd ...]
> 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'll be glad to send you - or submit another pr including - a patch
relative to -current that just adds the warning.

Which brings up another point.  Someone mentioned once that PR
submitters hear when their PRs statuses change.  I've sent in plenty of
PRs and can't recall ever getting anything back about any of them,
except the echo to netbsd-bugs.  Was the "someone" incorrect?  Or have
they just sat there so far?

>> 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.

Then as far as my need goes you might as well not have bothered; the
reason I put it there was so I could change it at runtime.  I would
still have composed and submitted a patch to make it writable somehow.

> 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).)

Arguing over whether /kern should or shouldn't exist is pointless.  You
said it yourself:

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

To put it another way, _I_ disagreed with _you_.

Now, since you don't have to use /kern, and I don't have to use
sysctl(8), I can't see any reason we can't each support our own
preferred method.  You prefer an efficient syscall introducing yet
another namespace; I prefer to sacrifice efficiency to have these
things appear in the existing filesystem namespace.

> Deal.

One can hardly term it a "deal" when one party's position is brushed
aside in favor of the other's.  I'm not asking you to add things to
kernfs; I'm perfectly happy to do the work myself.  And I'd even be
content if, when a change made for good reason elsewhere breaks kernfs,
you dump the problem on me.  But the impression I get is that you feel
thet NetBSD has to express _your_ idea of what is useful and/or good,
regardless of what others think.  This is not _per se_ a problem, but
you should probably then call it "chris-deraadt-mycroft-BSD"[%] rather
than "NetBSD", and not act as though you want people to send in their
tuppences.  (Lest you think I'm unaware of what it's like from your
side of the fence, I've written two pieces of software I can think of
offhand into which I've put code implementing things I think are bad
ideas, because others wanted them.)

[%] Names in alphabetical order - I don't know who else is core;
    majordomo@netbsd.org refuses to tell me.

When kstailey writes

> Maybe it's time to start an alternative NetBSD mailing list not
> associated with NetBSD.ORG to deal with all of the
> functionally-important stuff that got excluded because of egos,
> attitudes, aesthetics, standards or other good reasons to ignore
> ease-of-use.

this is the sort of concern I hear behind those words: that the
attitude behind your reaction to /kern/tickadj, or deraadt's reaction
to RCONS_WONB, is "I don't like it so it doesn't go in, I don't care
who may find it useful".  In at least the case of RCONS_WONB, I've had
one person specifically appreciate my doing it already...in direct
reaction to my frustrated letter.

chris replied to kstailey:

>> [...as quoted above...]
> If you think you're better served by somebody else, or another
> operating system, then what are you doing here?

As yet, I don't think so.  In reply to my frustrated letter, I've
received notes from two other people working on porting free OS code to
the SPARC.  I don't know whether either one will come as close to doing
what we want at the lab I work for (which is the major thing that got
me involved in NetBSD), but you can be sure I'm looking into them, and
if I decide they're better (including the stress of dealing with the
people as one of the factors), I'm outta here.  I'm sure you don't need
people uncomfortable using your system any more than I need a system
I'm uncomfortable using.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu