svn commit: r243627 - head/sys/kern

Alfred Perlstein bright at mu.org
Wed Nov 28 19:32:31 UTC 2012


Do you think we need another TRB?

It could be used to oust undesirable committers if needed. 

Sent from my iPhone

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

> 
> On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
> 
>> 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 
>> A> feet when developing FreeBSD.
>> A> 
>> A> Mistakes will happen, they will happen in head.  Slowing down the 
>> A> process to eliminate mistakes only works to slow down change and give a 
>> A> false sense of "fixing stability" when in fact the only thing "stable" 
>> A> is the slowness of submitting code.
>> 
>> This will eventually lead back to the situation when no one runs head,
>> because it is unusable.
> 
> Also, based on past experience: I'm much happier reviewing shaky code before 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 developing products against head, we can't let the quality of the head get back to the way it was in the 5.x timeframe. Several factors have led to our having a nearly-production quality development head over the last few years -- one is much heavier use of branched development for features (first Perforce, and more recently, Subversion, git, etc branches); the other is much heavier use of code review, especially for critical parts of the system. Device driver authors have a lot more leeway, but for core parts of the design, seeking review during development of a feature, and then before merging it upstream, should 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 yours, so as more people use review, the pool of potential reviewers goes up as well.
> 
> Robert


More information about the svn-src-head mailing list