Date: Tue, 15 Aug 2006 21:28:58 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Suleiman Souhlal <ssouhlal@freebsd.org>, current@freebsd.org Subject: Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes... Message-ID: <20060815212143.G45647@fledge.watson.org> In-Reply-To: <20060815180713.6a4ee2e6@Magellan.Leidinger.net> References: <20060815141151.15ae4349@Magellan.Leidinger.net> <44E1BD03.2030402@FreeBSD.org> <20060815144625.362bf376@Magellan.Leidinger.net> <44E1C3E4.7080508@FreeBSD.org> <20060815153451.604d16f1@Magellan.Leidinger.net> <44E1E85D.5070805@FreeBSD.org> <20060815180713.6a4ee2e6@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060815212143.G45647>