From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22439 invoked by alias); 1 Dec 2003 21:25:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22387 invoked from network); 1 Dec 2003 21:25:53 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 1 Dec 2003 21:25:53 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 63F2D2B8F; Mon, 1 Dec 2003 16:25:51 -0500 (EST) Message-ID: <3FCBB1DF.2050807@gnu.org> Date: Mon, 01 Dec 2003 21:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <1031124182547.ZM9776@localhost.localdomain> <3FC26407.9000704@gnu.org> <1031125000932.ZM11256@localhost.localdomain> <3FC60A75.8090803@gnu.org> <9178-Thu27Nov2003192422+0200-eliz@elta.co.il> <3FCB6275.2070403@gnu.org> <6654-Mon01Dec2003210731+0200-eliz@elta.co.il> <20031201191730.GA16428@nevyn.them.org> Content-Type: multipart/mixed; boundary="------------040906050001020504010803" X-SW-Source: 2003-12/txt/msg00029.txt.bz2 This is a multi-part message in MIME format. --------------040906050001020504010803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 979 > On Mon, Dec 01, 2003 at 09:07:32PM +0200, Eli Zaretskii wrote: > >> > Date: Mon, 01 Dec 2003 10:47:01 -0500 >> > From: Andrew Cagney > >> > > >> > > But that's precisely why we have the patch review and approval >> > > procedure, right? Maintainers who approve patches are supposed to >> > > prevent code that uses deprecated machinery from being added. > >> > >> > Very true. Explicit deprecation is a tool for making that part of the >> > maintainer and contributor task far easier. Instead of wasting time >> > trying to track and find all the things being eliminated, the >> > contributor and reviewer can simply keep an eye out for deprecated in >> > their patches > >> >> I'm not convinced that detecting STREQ is harder than detecting >> DEPRECATED_STREQ. > > > Neither am I... Andrew, how would you feel about a central (in the > source tree) list of deprecated objects instead? I see you didn't reply to the attached e-mail. Andrew --------------040906050001020504010803 Content-Type: message/rfc822; name="mailbox-message://ac131313@movemail/fsf/gdb/patches#8370148" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mailbox-message://ac131313@movemail/fsf/gdb/patches#8370148" Content-length: 3998 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: cagney@localhost.redhat.com Received: from localhost (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CCADA2B8F for ; Mon, 24 Nov 2003 17:14:31 -0500 (EST) Envelope-to: cagney@gnu.org Delivery-date: Mon, 24 Nov 2003 17:00:48 -0500 Received: from fencepost.gnu.org by localhost with IMAP (fetchmail-6.2.4) for cagney@localhost (single-drop); Mon, 24 Nov 2003 17:14:31 -0500 (EST) Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.24) id 1AOOlE-0006Ts-FZ for cagney@gnu.org; Mon, 24 Nov 2003 17:00:48 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AOPqd-0005XS-9e for cagney@gnu.org; Mon, 24 Nov 2003 18:10:58 -0500 Received: from [67.72.78.213] (helo=sources.redhat.com) by monty-python.gnu.org with smtp (Exim 4.24) id 1AOPqd-0005XE-2M for cagney@gnu.org; Mon, 24 Nov 2003 18:10:27 -0500 Received: (qmail 10750 invoked by alias); 24 Nov 2003 22:08:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Delivered-To: mailing list gdb-patches@sources.redhat.com Received: (qmail 10743 invoked from network); 24 Nov 2003 22:08:58 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 24 Nov 2003 22:08:58 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EC9BD2B8F; Mon, 24 Nov 2003 17:08:54 -0500 (EST) Message-ID: <3FC28176.5020908@gnu.org> Date: Mon, 24 Nov 2003 17:08:54 -0500 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <3FC119EB.1060102@gnu.org> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <3FC25DCF.7060508@gnu.org> <20031124205432.GA18415@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Content-length: 1114 > At least one now :) There are a number of other solutions to this. > Have you considered making the ARI mail contributors for certain > (low-false-positive) categories? Like, for instance, this one. The > gcc-regression mailing list has several scripts to pull the ChangeLog > entries since the last run and mail victims. It's extremely effective. I find the GCC script anything but effective. I get spammed everytime I commit something to GCC - a very negative experience for an infrequent GCC committer. I've now been conditioned into ignoring that mail :-( Contrast that to -Werror (yes ok, it isn't a requirement) and gdb_mbuild.sh. By encouraging their use we make it possible for people to address the problems _before_ they become an issue. That way the contributor and maintainer don't even need to discuss them. For something like the ARI to be mainlined, it would need to be integrated into the build process in a way that didn't leave the user confused (a standard build would have to be 100% warning free - something that at present is impossible to achieve). enjoy, Andrew --------------040906050001020504010803--