From owner-freebsd-hackers Thu Jun 3 22:49:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 8E9061532C for ; Thu, 3 Jun 1999 22:48:54 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id WAA14645; Thu, 3 Jun 1999 22:48:50 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA16912; Thu, 3 Jun 1999 22:48:50 -0700 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA20580; Thu, 3 Jun 99 22:48:47 PDT Message-Id: <375768A3.C556E77C@softweyr.com> Date: Thu, 03 Jun 1999 23:48:19 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: dyson@iquest.net, dillon@apollo.backplane.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 References: <199906040218.VAA05115@dyson.iquest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "John S. Dyson" wrote: > > > On Fri, 4 Jun 1999, Brian Somers wrote: > > > > > The system was becoming unstable due to Matts changes. Whether the > > > instabilities were in Matts code or somewhere else is irrelevent. > > > The reaction was (IMHO) the right thing to do. > > > > I think where the problem lied is very relevent. > > > > If the problems are not his fault are you saying he should have backed > > out his changes because they exposed old faulty code? What kind of > > progress is that? > > > The key is that if problems are going to be uncovered, then > understanding the rest of the code well enough to fix it > is important. There were not only cases of new or uncovered > bugs, but regression and mistaken removal of features that > weren't understood. All of the stuff requires some kind of > learning curve, and just jumping in and "coding" isn't really > a wise thing to do or allow. > > IMO, revokation of commit privs has given enough time to support > the learning curve and enforce a review process. I've been following this conversation with growing concern. It seems to me there is a fairly simple solution to this problem: create a branch for the ongoing VM work, enable commit privs on the branch for Matt and anyone else who's going to join in the fun, and then at times when they think it is appropriate and things have been adequately reviewed, we have a little merge-mania and things are better than ever. Are there any technological boundaries that prevent us from doing this? This is how we do it in the paid-for-code world. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message