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" <rwat...@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 your
 s, so as more people use review, the pool of potential reviewers goes up as 
well.
> 
> Robert
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to