svn commit: r243627 - head/sys/kern

[Robert N. M. Watson]

On 28 Nov 2012, at 19:32, Alfred Perlstein <bright at mu.org> wrote:

> Do you think we need another TRB?
> 
> It could be used to oust undesirable committers if needed. 

Are we seriously having a discussion in which the merits of favouring pre-commit code review for the things like TCP stack are in doubt? I'm not saying we need to seek universal consensus on all changes, rather, that I would strongly prefer that people committing to this code seek review (and clearly indicate it in commit messages) before rather than after sticking things in the tree. This stuff is incredibly subtle, and debugging problems in the field is vastly harder than catching them early in the cycle. I certainly wouldn't commit any non-trivial change to the code in question without asking someone to go through it line-by-line, and I'd prefer if others took the same view, as I often end up chasing the bugs later, in the field, where it is hardest to do so.

Robert

> 
> 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