Subject: Re: the path from nathanw_sa -> newlock2
To: Bucky Katz <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 02/14/2007 23:11:12
On Wed, Feb 14, 2007 at 04:23:09PM -0800, Bucky Katz wrote:
> "Jeremy C. Reed" <email@example.com> writes:
> > While I agree that discussion should be public, you should also consider
> > that also. As you planned and actually started to work on this, you could
> > have shared your plans (not necessarily code) to the appropriate tech-*
> > list or here at current-users. Or you could mention your plans in a PR bug
> > report.
> We've done all that. We've even tried to discuss these things on the
> #netbsd-devel and #netbsd-code IRC channels, in the hope that word
> would get to the right people.
I do not know what the #netbsd-devel and #netbsd-code IRC channels are
(though it seems fairly self-evident) nor who might have brought them
into existence, and I've been a NetBSD developer for well over ten years.
I do not see public mailing-list messages nor PRs from you (though I don't
know who else might work with you and might have posted such messages) that
contain the kind of information Jeremy seems to be talking about.
I think there is a fairly obvious communication problem here, but you,
on the other hand, seem to think it's all someone else's fault. I think
there is probably plenty of fault to go around, but I keep pretty good
tabs on all the official ways to communicate about NetBSD, and this is
the first I can ever remember seeing on this topic from you. That indicates
to me that that's probably true for a lot of other NetBSD developers as
Please, it would be nice if this silly bickering could stop, and we could
simply start communicating effectively. As I believe was mentioned in the
announcement of the threading change, I don't think anyone is going to
reject patches to make SA work again in the uniprocessor case -- but by
the same token, I don't think anyone is going to _produce_ such changes
just because you're angry, so it would be good if we could find a more
sensible way to resolve the problem the newlock2 integration has evidently
(and regrettably) caused for you.