Date: Thu, 16 Nov 2000 09:29:58 -0700 (MST) From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: will@physics.purdue.edu, arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC Message-ID: <200011161629.JAA04560@nomad.yogotech.com> In-Reply-To: <200011160923.CAA01986@usr02.primenet.com> References: <20001115180257.B26516@puck.firepipe.net> <200011160923.CAA01986@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Um, Terry, are you even on bugs@ ? The fact of life is, many folks who > > "try" -current that report bugs do not give enough details, so they in > > return get vague suggestions like these. > > No, I'm not. But I run -current on scratch disks from snapshots > because I can't afford the bandwidth to cvsup all the time Umm, Terry the amount of bandwidth you consume with email is close to the amount of bandwidth it would require for you to stay up-to-date with CVSup. I use it on a daily basis, and it takes literally minutes (not tens of minutes) to keep the tree up-to-date, except when tags are put down. >, and > because when you use cvsup, the lack of an interlock means that > the result is often unbuildable, particularly when it comes to > -current. If I can't afford one, then I can't afford the second > one that would be necessary, were I to have a failure. It doesn't build because the developers haven't taken the time to make sure it builds. This has little to do with lack of interlock. I can think of less than 2 dozen times in the 8+ years of FreeBSD where an interlock would have helped. Again, you speak w/out any experience, making you look like a fool. > Unfortunately, the cvsup date is not useful information for use > in a bug report, either. I would have to change my strategy to > doing a cvsup, and then backing off by date in GMT, until I got > something that compiled (not a winning strategy on a 386, in any > case). True, but it's the cost of doing bleeding edge development on a large project. Even monster projects have these sorts of problem, unless that have boatloads of people and hardware dedicately solely to the task of making sure the system builds. You aren't willing to help, why should you expect others to help? > It takes a prohibitive amount of disk cycles to do something like > this, and hosted cross-builds are still not that easy, unless you want > to dirty your main source tree and the /sys link, or unless your > scratch disks are really massive suckers. Cross-builds are trivial is you stick them in /chroot partition. (Julian did this initially with 'ref.tfs.com', and I've followed it since with great results in almost all cases.) Also, 'disk cycles' are free if this host in indeed a 'scratch' host, or did your computer start charging you more for being busy instead of being idle? (Or more to the point, do you have alot of other processes that your proverbial 386 must be busy doing instead of builds?) > Using snapshots avoids the CPU cycles problem and the cvsup data > synchronization problem: a snapshot is not made available until > it can at least successfully compile. Sure, and it's out-of-date as well. > So you could ammend my statement, I suppose, to ``clued people > "try" snapshots to reduce the number of useless answers to their > bug reports''. If it doesn't build, it's pretty tough to give out 'bug reports' of the type the developers are asking for (back-traces, etc..), simply because the system can't build. 'It doesn't work' bug reports come in often, and those in themselves are decent as long as the submitter gives enough error information on where it's broken. > So in summary, I don't need to be on "bugs@" today, since I'm Let me rephrase that again, for the Terry-impaired: "Because I'm a know-it-all and everyone ignores me anyway, because I often complain about non-existant bugs that only exist in my brain. Plus, I send out some much email that any bits of useful knowledge are lost in the incredible amount of noise I generate." Honestly Terry, you're a bright guy. But, you aren't nearly as bright as you think you are. People might take you seriously if you stuck to topics that you *do* know something about, and try to tone down both the length of your email as well the amount of politics your portray. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011161629.JAA04560>