Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2012 11:32:27 -0800
From:      Alfred Perlstein <bright@mu.org>
To:        "Robert N. M. Watson" <rwatson@FreeBSD.org>
Cc:        "src-committers@FreeBSD.org" <src-committers@FreeBSD.org>, Andre Oppermann <andre@FreeBSD.org>, Peter Wemm <peter@wemm.org>, "svn-src-all@FreeBSD.org" <svn-src-all@FreeBSD.org>, Gleb Smirnoff <glebius@FreeBSD.org>, "svn-src-head@FreeBSD.org" <svn-src-head@FreeBSD.org>
Subject:   Re: svn commit: r243627 - head/sys/kern
Message-ID:  <645253DB-A722-477B-8E86-FDBD9E3E58C4@mu.org>
In-Reply-To: <41E6060B-5A74-4524-9011-2BFFF5B47E24@FreeBSD.org>
References:  <201211272004.qARK4qS8047209@svn.freebsd.org> <CAGE5yCpxOdsjefe6quR_gjs82pk9a2e_H_WUNUWhUGA3WZPJaw@mail.gmail.com> <50B54180.5020608@freebsd.org> <alpine.BSF.2.00.1211272246560.37292@fledge.watson.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>

next in thread | previous in thread | raw e-mail | index | archive | help
Do you think we need another TRB?

It could be used to oust undesirable committers if needed.=20

Sent from my iPhone

On Nov 28, 2012, at 10:25 AM, "Robert N. M. Watson" <rwatson@FreeBSD.org> wr=
ote:

>=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 befo=
re it goes into the tree than trying to debug it in situ and having to back i=
t out. If our advice to many companies is that they should start developing p=
roducts against head, we can't let the quality of the head get back to the w=
ay it was in the 5.x timeframe. Several factors have led to our having a nea=
rly-production quality development head over the last few years -- one is mu=
ch heavier use of branched development for features (first Perforce, and mor=
e recently, Subversion, git, etc branches); the other is much heavier use of=
 code review, especially for critical parts of the system. Device driver aut=
hors have a lot more leeway, but for core parts of the design, seeking revie=
w during development of a feature, and then before merging it upstream, shou=
ld be an expectation for all but the most trivial of changes. It's a two-way=
 street, of course: if you review other people's code, they will review your=
s, so as more people use review, the pool of potential reviewers goes up as w=
ell.
>=20
> Robert



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?645253DB-A722-477B-8E86-FDBD9E3E58C4>