Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Dec 2001 12:33:12 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Greg Lehey <grog@FreeBSD.org>
Cc:        Bruce Evans <bde@FreeBSD.org>, Matt Dillon <dillon@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, FreeBSD Core Team <core@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/dev/sio sio.c
Message-ID:  <Pine.NEB.3.96L.1011223120751.8511h-100000@fledge.watson.org>
In-Reply-To: <20011223133156.I88202@monorchid.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 23 Dec 2001, Greg Lehey wrote:

> (dons -core hat)
> 
> Come on, people, this isn't appropriate behaviour.  I'd have expected a
> more mature approach from both of you.  Please don't touch these sources
> until we've had time to talk about it (which probably means at least 24
> hours).

For whatever it's worth, here's my view: Bruce and Matt need to go sit in
their respective corners for a few minutes, take a deep breath, and come
back when they're ready.  As I see it, there's plenty of fault to go
around for everyone.

Matt probably should have run the patch by Bruce before committing it: 
common courtesy dictates contacting the maintainer to give them a pass is
a reasonable thing to do.  A casual glance at the sio.c history reveals a
fair number of Bruce's 'Reviewed by's, although they are not universal. 
As there was no rush in getting it committed (we've lived with the problem
for ages, another 48 hours would have hurt no one), this seems a
reasonable course of action.  If Matt anticipated objections from Bruce,
that suggests arch@FreeBSD.org as the place to take those concerns.

Bruce should not have immediately backed out the fix -- an objection by
e-mail would have been quite sufficient, asserting a maintainer bit and
requesting a backout, and any technical concerns about the problems with
the commit.  A solution appears to be needed, whatever that solution may
be, so taking the concerns seriously is important.  I was actually quite
surprised to see Bruce's immediate backout: Bruce has a long history of
taking concerns with commits to the committers out-of-band, and often runs
for years with local fixes to problems introduced on the main tree and
never accepted back by the introducer of the problem.

Likewise, Matt should not immediately have backed out the back out: he
received a specific complaint from the maintainer of the code saying that
solution was inappropriate.  Feelings about the technical merits of the
commit are not relevant in this situation, as it's clearly a conflict
resolution scenario in a case where an administrative tool (MAINTAINER) is
being used.  Asserting the negligence of Bruce in fixing a problem doesn't
help: he didn't present any evidence that he'd previously raised the
problem, making a rapid and unreviewed commit of a fix unjustified.  Even
assuming Bruce's commit was agressive and un-called for (reasonable
conclusions), that response takes Matt down to Bruce's level, in my eyes. 
It was clearly retaliatory, and inappropriate. 

It seems like a reasonable conclusion, therefore, that Bruce and Matt both
acted inappropriately.  I don't really have any opinion concerning the
technical fix: there are almost always multiple valid ways to solve a
problem Bruce's opinion certainly counts for something, as the maintainer
of the code and as one with lots of experience using and modifying the
code, and Matt's opinion counts due to specific material problems
experienced.  There was no need to rush the commit, the backout, and
certainly no need to back out the backout.

I think we all believe there's a problem with what is there right now: on
at least two -CURRENT i386 boxes I have, I frequently experience silo
overflows.  I haven't experienced them in -STABLE lately, but certainly
used to.  And Doug Rabson has reported similar problems on the Alpha
platform.  Even if the real fix is to improve interrupt latency problems,
we will need a temporary fix, as some of those interrupt problems appear
to be inherrent to the gradual SMPng development process we've adopted.

In the future, I'd appreciate it if both Matt and Bruce would wait at
least 12 hours before backing out changes under circumstances like these. 
Preferably 48 hours.  And take a deep breath before getting involved in
this sort of argument.  Under such circumstances, it's rare for any one
person to be 100% right, which means that acting righteously to liberate
source code from the hands of an oppressor (either one) is inappropriate
at best, and really quite disruptive in practice. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011223120751.8511h-100000>