HEADS-UP: starting to commit linuxolator (SoC 2006) changes...
rwatson at FreeBSD.org
Tue Aug 15 20:29:00 UTC 2006
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
> 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
University of Cambridge
More information about the freebsd-current