Date: Mon, 12 Sep 2005 19:28:51 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: David O'Brien <obrien@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_tc.c src/sys/net rtsock.c src/sys/netipx ipx_proto.c src/sys/netnatm natm_proto.c Message-ID: <20050912192330.P96771@fledge.watson.org> In-Reply-To: <20050912181727.GA96329@dragon.NUXI.org> References: <200509071006.j87A6E8s012380@repoman.freebsd.org> <20050911222701.W33344@fledge.watson.org> <20050912013616.GA78451@dragon.NUXI.org> <20050912094446.P33344@fledge.watson.org> <20050912181727.GA96329@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Sep 2005, David O'Brien wrote: > Suppose that thru a long multi-month discussion with the TRB and parts > of Core a matrix was created what was officially supported of what > builds on what. And also stated what was should be kept building on > what if reasonable to do so. And stated what wasn't supported. > > The build situation you championed wasn't even contemplated - it isn't > one we'd run into to even consider having it in the matrix. > > I know for a fact that a RELENG_5 config(8) won't config a -CURRENT > kernel. So you must have built a -CURRENT config(8) on your RELENG_x > box (or be prepared to). You could also build -CURRENT gcc+binutils on > your RELENG_x box and install it for use in building HEAD kernels. So it would appear: zoo:/zoo/rwatson/p4/projects/netsmp/src/sys/fs/fifofs% ls ~/bin ./ config4* config61* ministat* ../ config6* config62* p4* Easy to do it with config, a pain to do it with a complete toolchain. I have to say that the NOMAN->NO_MAN changes last year were among the most annoying of this sort we've had in ages, since there was little or no effort at forwards compatibility for builds. This required custom modification of the module Makefile for aic7xxx for every kernel source code tree I work with, which was also a waste of time. >> On my desktop (P4 1.8GHz, 512MB), it takes 15 minutes per kernel tools >> build, which assuming I built them on the three machines sequentially, >> would result in spending 9 hours rebuilding kernel tools as a result of >> introducing dependencies on compiler tweaks before merging them. > > Honestly, a 1.8GHz Intel (or AMD 1800+) desktop CPU is 4 years old. > For some one building 12 active branches a day, I think you would be > more than justified in asking for a more powerful desktop at > http://www.freebsd.org/donations/wantlist.html With both Intel and AMD > have dual-core desktops - allowing you to have a cheap SMP machine, its > a good time to ask on wantlist.html. While the build time is huge, it's much more the management time that makes it an issue: as I said, keeping 12 branches with in sync toolchains is very time-consuming, and adds overhead to day-to-day development that, in the general case, is unnecessary. >> So the difference between it working may be gravy to you, but it's the >> difference between spending several days of my FreeBSD time chasing >> build tool changes over a dozen branches and several machines and >> spending those days doing productive work. Which isn't to say that >> progress shouldn't happen, just that a minor change in the order of >> commits would have saved me a lot of time. > > There are 100's and 100's of FreeBSD commits that if ordered or done > slightly differently would have saved me hours and hours and hours. > That, unfortunately, is the life of a committer in FreeBSD'ville. No doubt. Yet you'd think that avoiding unnecessary inconvenience would be something you'd consider desirable, given that... Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050912192330.P96771>