Date: Fri, 03 Dec 1999 18:17:45 -0700 From: Warner Losh <imp@village.org> To: obrien@FreeBSD.org Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_bus.c Message-ID: <199912040117.SAA14552@harmony.village.org> In-Reply-To: Your message of "Fri, 03 Dec 1999 16:57:13 PST." <19991203165713.A1939@dragon.nuxi.com> References: <19991203165713.A1939@dragon.nuxi.com> <Pine.BSF.4.05.9912030858490.12054-100000@semuta.feral.com> <199912031701.KAA11135@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <19991203165713.A1939@dragon.nuxi.com> "David O'Brien" writes: : Often one does not need to do a `make world' to catch syntax errors. A : simple make of program (or kernel) would do. A `make world' is [mostly] : only needed to test interactions in the build process. One problem is that of forgotten checkins. I almost always checkin building code. However that is "building on my machine" rather than "building with a fresh set of sources." Several times I've had the problem of neglecting to checkin a change to a file that has changed/been added. Many other people have had this problem as well, and I know that the software compiles for them. There are many times new source will be imported which doesn't compile, but the import must be on a vendor branch unmodified. The files are then pulled off the vendor branch and made to compile shortly after the initial commit. Finally, there have been instances where I change files foo and bar and make my commit. Bob changes files baz and boo and makes his commit. The confluance of these changes causes a problem, but each change taken singlely doesn't have the problem. This has happened in the past as well. Automating a 'it must compile to be committed' rule is hard to do, despite its desitrability. The simple fact of life is that the FreeBSD will be unbuildable from time to time and history has shown that these periods rarely last more than a few hours (although serveral days in a row snapshots may be broken by different people each day). The more mainstream the breakage (eg no kernels can be built) gets faster attention than the less mainstream (eg make release fails) due to the relative numbers of people doing each one. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912040117.SAA14552>