Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes...

On Tue, 15 Aug 2006, Alexander Leidinger wrote:

>>> How many percent of the code I committed is not reviewed and how much is 
>>> this related to the amount of unreviewed code committed in a busy week?
>>
>> I don't want to sound harsh or like I'm doubting Roman's ability, but most 
>> of the unreviewed code that gets committed comes from people who have more 
>> experience than Roman and who usually "own" the part of the kernel they are 
>> touching.
>
> This doesn't help when the code in question isn't owned like the 
> linuxolator. Because most of the new code will not affect the rest of the 
> system (only linux programs, if at all), I don't think committing this now 
> was a big mistake.

I'd like to see this handled better in the future, myself.  In the past 24 
hours several reviews have come in -- unfortunately, all after the commit, 
because almost no time was given for the reviews to be done before the commit. 
Given that there have been several replies on the perforce list indicating 
that sections of the changes weren't yet in an acceptable form for committing 
(i.e., broken), waiting for that to settle out before committing makes a lot 
of sense.  -CURRENT is here to provide communal testing, but that doesn't mean 
that broken code should be committed intentionally.

Over the past 3-4 years, the standards for committing code to -CURRENT have 
gone up *significantly*, and -CURRENT should not be considered a 
"free-for-all".  It's the base branch for an enourmous amount of other work, 
and if -CURRENT gets broken, that holds up all the dependent work.  Waiting 
three or four days after a patch is posted for reviews to come in is a 
reasonable minimum expectation for a large set of changes, especially when 
it's clear that there are people out there willing to review the changes (vis 
P4 submit replies).

We have Perforce available for exactly this reason: works in progress can 
remain outside the tree until they can be adequately reviewed and tested, 
rather than having to be committed quickly in order to keep them in revision 
control.  This became critical a few years ago when it became clear to 
everyone that the project had grown to a point where having the "-CURRENT can 
be broken at any time" assumption wasn't sustainable, as it meant -CURRENT was 
broken all of the time.  We can't go back to that, and that means that 
everyone who is committing to -CURRENT needs to hold themselves to high 
standards of review and testing.

I.e., I think this commit was a mistake.  I'm not asking for it to be backed 
out, but given the uproar it's caused, and the amount of immediate feedback on 
problems in the patch, waiting another two days to get that feedback and fix 
the problems is a minimal expectation for committing to the kernel.

Robert N M Watson
Computer Laboratory
University of Cambridge