From owner-freebsd-stable Sun Jul 9 13:37:21 2000 Delivered-To: freebsd-stable@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 6611537BF96 for ; Sun, 9 Jul 2000 13:37:15 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id PAA15666; Sun, 9 Jul 2000 15:37:05 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-81.max1.wa.cyberlynk.net(207.227.118.81) by peak.mountin.net via smap (V1.3) id sma015641; Sun Jul 9 15:36:27 2000 Message-Id: <4.3.2.20000709144723.00c67580@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 09 Jul 2000 15:35:27 -0500 To: Michael Robinson , freebsd-stable@FreeBSD.ORG From: "Jeffrey J. Mountin" Subject: Tracking -stable (was Re: Synching my src...) In-Reply-To: <200007090857.QAA84590@netrinsics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 04:57 PM 7/9/00 +0800, Michael Robinson wrote: >"David O'Brien" writes: > >You did remember correctly, but you seem to have missed the "all's OK" > >message that went out 2 days ago. > >This is a pet peeve of mine. Freebsd-stable is supposed to be the mailing >list that is required reading for anyone tracking stable, where all useful >information related to tracking stable is to be found. And what does this have to do with the subject you used? Hmmm... >However, the list is increasingly such a high-volume, low >signal-to-noise-ratio >chatfest that it no longer serves its intended purpose for even moderately >busy people. A prohibitive amount of time is required to sort out what is >relevant from what isn't. This is the price one pays for tracking -stable and being on a mailing list. Yet I agree that it has been a bit more noisy than usual. >Would it be possible to create a freebsd-stable-announce list whose sole and >exclusive content is informative, authoritative messages related to the >proper downloading, installation, configuration and running of freebsd-stable? Great, then most will need to track yet another list. Why not just watch the commits and check the -stable list when you run into a problem. Adding another list would not help the problem. Someone then has to decide what goes where and if it doesn't fit what you want.. This is a catch-22 situation, IMO What bothers and amuses me to no end are those that complain about building problem, *after* a number of messages have been sent to the list *after* a heads up *and* they are building with sources that are not up to date. Considering the number of recent changes I've been holding off on cvsup'ing and have exactly 300 message for commits to -stable since last buildworld on 6/27. Fact is, I was going to re-synch about a week back, but after some lib changes held off, since lib changes are the biggest pain in the a^Hports at times. After that the tree changes and cc/binutils as well as a few build problems and an SMP issue, decided to sit back and wait. Considering the number of commit-fests going on the past 10 days by David E. O'Brien, Matt Jacob, Paul Saab, and Nick Hibma (not that I use USB) there are those that paid the price by trying to keep up and missing parts of the various critical updates. My point is everyone doing a build should pay attention to the list and when a build problem goes away and they successfully complete a build they add a "(solved)" to the message thread. This should help those less experienced. Personally I think there are too many either trying too hard to track -stable and building too often or doing so for no reason other than to "just do it." Certainly those doing the commits want a large audience to determine if there are any problems with an MFC, but then as an MFC there should have been a testing/trial period in -current. Considering the traffic will be going up considerably with 4.1R around the corner, I'd ask that there be a limit on the "me too" type messages. I must admit that doing so is not as bad as having a half dozen "build problem" messages covering the same error. Before posting a problem one should check and read mail, both -stable and cvs. The first may contain a fix for testing or mention a recent commit. Checking cvs after a failed build may show a commit to the file(s) that build breaks on. By checking it in the first place you might be clued in that someone is actively committing and it might be good to wait. Basically cvsup, build, oops error, check mail, cvsup again (may have missed a commit), and try building again after blowing away /usr/obj (like one should unless they know better). Then if it fails check mail and finally send a message. There seems to be a slew of memory/hardware related build problems. Perhaps there should be mention of the signs of possible memory/hardware build issues somewhere other than the docs and web page. Then again, many don't RTFM, so what use. Think I'll step down now, check mail again , cvsup, and clean out my inbound commits. Pardon the rant, but hopefully added some insight and not too much noise. 8-) To be fair, I think it is OK to speak up quickly when the X.Y-RC's are out. The higher traffic should be considered the price paid for a more perfect release. Just check and read mail first. ;) Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message