From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30780 invoked by alias); 1 Dec 2003 15:47:02 -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 30709 invoked from network); 1 Dec 2003 15:47:01 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 1 Dec 2003 15:47:01 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CAA542B90; Mon, 1 Dec 2003 10:47:01 -0500 (EST) Message-ID: <3FCB6275.2070403@gnu.org> Date: Mon, 01 Dec 2003 15:47: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: Eli Zaretskii Cc: kevinb@redhat.com, drow@mvista.com, 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> <1031124182547.ZM9776@localhost.localdomain> <3FC26407.9000704@gnu.org> <1031125000932.ZM11256@localhost.localdomain> <3FC60A75.8090803@gnu.org> <9178-Thu27Nov2003192422+0200-eliz@elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00009.txt.bz2 >> Date: Thu, 27 Nov 2003 09:30:13 -0500 >> From: Andrew Cagney >> >> If a contributor wants to add new code, or fix bugs in existing code, >> they should not be increasing the use of existing deprecated mechanisms >> (after all we should be able to reasonably expect contributors to not >> make matters worse). > > > 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 (and related calling). This then lets both parties focus their attention and efforts on the real reason for the review - ensure code quality and correctness. Andrew