From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: eshell-defgroup. Do we really need this? Date: Tue, 05 Aug 2008 17:20:00 +0900 Message-ID: <87vdyfg9fz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080729222754.GC2208@muc.de> <86myjx3lt8.fsf@lifelogs.com> <48921019.6030308@gmail.com> <8663qk3g0w.fsf@lifelogs.com> <87y73giryj.fsf@elegiac.orebokech.com> <86iquk1nsk.fsf@lifelogs.com> <878wvgm4mw.fsf@uwakimon.sk.tsukuba.ac.jp> <86zlnszql2.fsf@lifelogs.com> <87sykiguzc.fsf__45993.8457854607$1217872198$gmane$org@uwakimon.sk.tsukuba.ac.jp> <86vdygzku5.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217924451 19069 80.91.229.12 (5 Aug 2008 08:20:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Aug 2008 08:20:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 05 10:21:42 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KQHnV-0006x0-Uk for ged-emacs-devel@m.gmane.org; Tue, 05 Aug 2008 10:21:38 +0200 Original-Received: from localhost ([127.0.0.1]:56570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQHma-0002d1-CO for ged-emacs-devel@m.gmane.org; Tue, 05 Aug 2008 04:20:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQHmV-0002c3-Dn for emacs-devel@gnu.org; Tue, 05 Aug 2008 04:20:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQHmT-0002ac-8I for emacs-devel@gnu.org; Tue, 05 Aug 2008 04:20:34 -0400 Original-Received: from [199.232.76.173] (port=34521 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQHmS-0002aK-SZ for emacs-devel@gnu.org; Tue, 05 Aug 2008 04:20:33 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:38394) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQHmR-0000vZ-Pj for emacs-devel@gnu.org; Tue, 05 Aug 2008 04:20:32 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id D82C77FFC; Tue, 5 Aug 2008 17:20:19 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 31C7B1A25C3; Tue, 5 Aug 2008 17:20:00 +0900 (JST) In-Reply-To: <86vdygzku5.fsf@lifelogs.com> X-Mailer: VM ?bug? under XEmacs 21.5.21 (x86_64-unknown-linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102079 Archived-At: Ted Zlatanov writes: > I guess I come from a background of sysadmin, where things that can go > wrong will, so I'd rather not assume this. I've had enough experience > with "this should never happen" happening at 3 AM. That's just an argument for never doing any testing, since *any* test could fail due to a flaky memory chip. > What I'm trying to help provide is a proactive mechanism. Then look elsewhere than buildbot, which is just an attempt to speed up the reaction. A proactive solution would be to convince the Scons people to join GNU. > SJT> XEmacs and SXEmacs see *way* fewer "broken build" reports, and when > SJT> we do, the response is almost always that the responsible developer > SJT> pipes up with "oops, my bad, fixed" within 24 hours. I've *never* > SJT> seen the kind of "Did you wait until the goat died? You can't > SJT> start the build before the sacrificial goat is dead!" threads that > SJT> are so common on emacs-devel. > > Well, maybe that will change when we can identify the change that broke > the builds. I am not trying to change social dynamics, regardless. That wasn't a diagnosis, that was a description of a painful symptom. We've got a patient with a migraine, and he's *not* holding a hammer. That is, this thread was occasioned by breakage that happened to *one* person, and we do not yet know what caused that problem. Since the details the OP has since given "shouldn't happen" the maintainers are almost certainly going to table the matter and wait for more evidence. The buildbots won't help with that. What buildbots can do is point out the easy ones quickly. Note that Alan used several methods to ensure a "clean" build; none of them worked. If there were a buildbot for his platform and configuration, then you could say, "OK, bot is green, so let's see what is 'dirty' about your environment." > My suggestion was to look for 5 or more broken build reports from > buildbots in the community. I think you vastly overestimate the number of buildbots that will be forthcoming. > I could go on, but the point is a broken build from a single system > can be caused by too many factors external to the build process. Surely you can distinguish between the number of ways to go wrong and the probability of going wrong? The evidence I've seen in the Python project is that nobody has ever complained in about 2 years of running buildbots of spurious reports. The vast majority of red bots are bugs in the Python build or regressions.