From owner-cvs-all Tue Oct 29 12:29:29 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E73F937B404; Tue, 29 Oct 2002 12:29:27 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E8E443E6E; Tue, 29 Oct 2002 12:29:27 -0800 (PST) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id DE1544CEA5; Tue, 29 Oct 2002 15:29:22 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA16514; Tue, 29 Oct 2002 15:29:21 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA09451; Tue, 29 Oct 2002 12:29:21 -0800 (PST) Message-Id: <200210292029.MAA09451@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: obrien@FreeBSD.org Subject: Re: cvs commit: src/lib/libfetch common.c Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org References: <200210291702.JAA05652@windsor.research.att.com> <20021029195921.GC42760@dragon.nuxi.com> Date: Tue, 29 Oct 2002 12:29:21 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Why is FreeBSD's attitude one of all changes are totally justified and if >a change breaks something it is up to the one feeling the new breakage to >justify any further change? That's not my attutide. My attitude is that forward progress, even if bumpy, is better than backward progress. If I had your attitude, I would have backed out rev 1.27 of common.c, because that was what started my problem with firewalls, instead of writing the patch in PR bin/44123. I recognized that SSL was a useful addition to fetch, so worked to move it forward instead of backward. >We really need to change our attitude to one that a change that causes a >problem is backed out (ie, unbreaks world), and then the change is >reviewed to see what went wrong. I don't think an "insta-backout" is called for, especially if the code works in the majority of cases and only fails in a small number (like was the case here). If the issue can't be resolved reasonably in a small number of days, then a backout may be called for, but backing something out because you couldn't find someone to talk to about it at 3:00AM is ludicrous. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message