Bill Studenmund <wrstuden@netbsd.org> writes:

> Actually, it's not a social problem. Maintaining two totally divergent 
> code bases is a technical problem.

It would be. That's not what we are asking for here.  We're asking for
a kernel compile time define that turns on a feature if requested and
we'll maintain that feature once you've restored it.

This is no different than N other kernel compile time features that
every OS that's had more than one release finds itself dealing with.

> It's one thing for there to ba an SA option that can be enabled in a
> UP kernel. It's another for there to be two different scheduler
> infrastructuers and two different interrupt infrastructures. The
> latter is not maintainable.

I disagree. See above.

> Bucky, what do you want?

Which part of what I've asked for isn't clear?

I want y'all to communicate with your users before you dump
functionality.

I want an evbarm port maintainer who actually maintains the port.

I want m:n threads back in the uniprocessor case, something I was
working with people to make happen before Jason showed up out of
nowhere with his fiats.

I want to contribute a bunch of stuff back to NetBSD, but y'all are
making me want that less all the time.

I want the NetBSD developers to do this as an act of good faith, so I
can use that act in arguments about why we should have just used Linux
in the first place.

I want half a dozen other changes I've communicated to core and have
been told are reasonable.

> You claim you want things to work. However you are being routinely
> abrasive and rude. This behavior pattern is not encouraging others
> to actually help you. You have been told this. This is a volunteer
> project, and as such it matters how you ask for things.

Oh dear, let's make the failure of the NetBSD developers to work with
its user community all about me showing some frustration after months
of trying to be polite.

Yes, indeed, it _does_ matter how you ask.  I tried polite. Got zero
back for six months.  Now I'm trying direct.  If that doesn't work
then I'll reduce my team's committment to NetBSD.

> So why, if you really want things to work, are you continuing to
> behave in a manner that you have been told will not encourage others
> to make SA or M:N work?

Well, given that people have fairly abrasively told me that they're
not going to make SA or M:N work, even when I did ask politely, at the
start of this exchange, I'm not seeing where I'm losing anything at
this point.

> While Jason is not core, he started the newlock branch way back
> when. He also knows a fair amount about how the scheduler works and
> how this part of the kernel works. His input, that a revived SA
> would need to be adapted to cope with a changed scheduler, is the
> exact kind of input core would need to answer your request.

Then, perhaps, he should have offered advice to core, rather than flat
fiats to the users.