From owner-svn-src-head@FreeBSD.ORG Wed Nov 28 21:00:18 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E05D129; Wed, 28 Nov 2012 21:00:18 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B60298FC0C; Wed, 28 Nov 2012 21:00:17 +0000 (UTC) Received: from [10.141.19.129] (unknown [212.183.128.188]) by cyrus.watson.org (Postfix) with ESMTPSA id 27D2D46B09; Wed, 28 Nov 2012 16:00:17 -0500 (EST) References: <201211272004.qARK4qS8047209@svn.freebsd.org> <50B54180.5020608@freebsd.org> <50B54492.5040100@freebsd.org> <956CE44A-BA0F-4FE4-AA38-F4B90C85ECBA@FreeBSD.org> <50B54CE0.6080008@freebsd.org> <2A12C740-1D72-4D30-B663-47A37AAC2FF3@FreeBSD.org> <50B5C4F1.1020002@freebsd.org> <50B64C43.50001@mu.org> <20121128175116.GI14202@FreeBSD.org> <41E6060B-5A74-4524-9011-2BFFF5B47E24@FreeBSD.org> <645253DB-A722-477B-8E86-FDBD9E3E58C4@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <645253DB-A722-477B-8E86-FDBD9E3E58C4@mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: "Robert N. M. Watson" Subject: Re: svn commit: r243627 - head/sys/kern Date: Wed, 28 Nov 2012 21:00:13 +0000 To: Alfred Perlstein Cc: "src-committers@FreeBSD.org" , Andre Oppermann , Peter Wemm , "svn-src-all@FreeBSD.org" , Gleb Smirnoff , "svn-src-head@FreeBSD.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 21:00:18 -0000 On 28 Nov 2012, at 19:32, Alfred Perlstein wrote: > Do you think we need another TRB? >=20 > It could be used to oust undesirable committers if needed.=20 Are we seriously having a discussion in which the merits of favouring pre-co= mmit code review for the things like TCP stack are in doubt? I'm not saying w= e need to seek universal consensus on all changes, rather, that I would stro= ngly prefer that people committing to this code seek review (and clearly ind= icate it in commit messages) before rather than after sticking things in the= tree. This stuff is incredibly subtle, and debugging problems in the field i= s vastly harder than catching them early in the cycle. I certainly wouldn't c= ommit any non-trivial change to the code in question without asking someone t= o go through it line-by-line, and I'd prefer if others took the same view, a= s I often end up chasing the bugs later, in the field, where it is hardest t= o do so. Robert >=20 > Sent from my iPhone >=20 > On Nov 28, 2012, at 10:25 AM, "Robert N. M. Watson" w= rote: >=20 >>=20 >> On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote: >>=20 >>> On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrote: >>> A> Personally I don't think we need any more anchors attached to people'= s=20 >>> A> feet when developing FreeBSD. >>> A>=20 >>> A> Mistakes will happen, they will happen in head. Slowing down the=20 >>> A> process to eliminate mistakes only works to slow down change and give= a=20 >>> A> false sense of "fixing stability" when in fact the only thing "stable= "=20 >>> A> is the slowness of submitting code. >>>=20 >>> This will eventually lead back to the situation when no one runs head, >>> because it is unusable. >>=20 >> Also, based on past experience: I'm much happier reviewing shaky code bef= ore it goes into the tree than trying to debug it in situ and having to back= it out. If our advice to many companies is that they should start developin= g products against head, we can't let the quality of the head get back to th= e way it was in the 5.x timeframe. Several factors have led to our having a n= early-production quality development head over the last few years -- one is m= uch heavier use of branched development for features (first Perforce, and mo= re recently, Subversion, git, etc branches); the other is much heavier use o= f code review, especially for critical parts of the system. Device driver au= thors have a lot more leeway, but for core parts of the design, seeking revi= ew during development of a feature, and then before merging it upstream, sho= uld be an expectation for all but the most trivial of changes. It's a two-wa= y street, of course: if you review other people's code, they will review you= rs, so as more people use review, the pool of potential reviewers goes up as= well. >>=20 >> Robert