From owner-freebsd-stable@FreeBSD.ORG Sun Aug 17 15:14:20 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0FD837B401 for ; Sun, 17 Aug 2003 15:14:20 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F125F43F3F for ; Sun, 17 Aug 2003 15:14:19 -0700 (PDT) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (adsl-68-120-131-157.dsl.snfc21.pacbell.net [68.120.131.157]) h7HMEDoM014615 for ; Sun, 17 Aug 2003 17:14:18 -0500 (CDT) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.12.9/8.12.9) with ESMTP id h7HMEG5W048603 for ; Sun, 17 Aug 2003 15:14:16 -0700 (PDT) (envelope-from edhall@screech.weirdnoise.com) Message-Id: <200308172214.h7HMEG5W048603@screech.weirdnoise.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: stable@freebsd.org In-Reply-To: Message from Andy Sparrow <20030817210218.8F0C9C4@CRWdog.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Aug 2003 15:14:16 -0700 From: Ed Hall Subject: Re: [releng_4 tinderbox] failure on alpha/alpha X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 22:14:21 -0000 On Sun, 17 Aug 2003 14:02:18 -0700, Andy Sparrow writes: > > > The same thing started in -PORTS quite some time ago, where I find > > > personally find that it generates more cr@p than the real traffic at > > > times. > > > > You're entitled to your opinion, > > Thanks, I will clarify it further for you. > > > but since you've never had to deal > > with the flood of support requests when INDEX builds were broken by > > careless committers before I started the automated tinderbox, > > Wouldn't the real issue be to control the careless committers then? Or > to target them specifically and directly with the Tinderbox failures? > > When I automated overnight builds of mutiple branches of a commercial > product on mutiple OS platforms, sending those build results > company-wide was never considered as an option. > > I just don't see why it isn't more appropriate to simply limit the > messages to people with a commit bit, a specific email alias, or even > people who checked stuff in since the last sucessful Tinderbox. > > > I'd > > suggest you try to consider it from point of view of those of us who > > are actually involved in the support of the OS. > > It's not that I don't appreciate the efforts that are being made so much > as I question the elegance of the solution employed. > > Some people pay for (limited) bandwidth by time on-line, and cannot > filter except after receipt, thus have no choice but to *pay* to > retrieve those messages before filtering them, so it's not simply a > question of whether they "just hit delete" or filter them out or > whatever. > > Those messages thus inevitably dilute the value of the list for them, I > suggest you try to consider it from *their* point of view. > > There's also the issue that all the descriptive fields for -STABLE and > -PORTS say that these are "discussion" lists - which *used* to be true. > Multiple posts from Bots don't make for much of a "discussion", in my > book. > > Whatever. Procmail works for me, but not everyone has that choice. The tinderbox posts are quite valuable -- more valuable than most of the posts here (including this one). They can save me and others here a lot of time since they let me know whether or not CVS is in a buildable state. They are sent to -stable for a couple of reasons that I can see: 1) Users are instructed to read -stable if they are running STABLE, and check the list before they report problems to see if a problem has already been reported. A tinderbox failure is such a problem report, and no less valuable for being automatically generated. And even if a build on a different architecture than you're using is the one that is breaking, it is often a symptom of a problem that could affect everyone. 2) Sending build failures to a semi-public list provides peer pressure on committers to fix their stuff, quickly. Despite your claim to the contrary, commercial organizations (even one I can think of in Redmond, WA) do this inside their engineering groups. Subscribers to freebsd-stable form a similar group of peers and internal customers. When a build fails, work cannot progress. It's an urgent situation. A lot of people are affected, not just the committer who broke the build or even just committers in general. Perhaps *you* aren't affected, but honestly, now, what percentage of messages on this list directly affect you? -Ed