From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31718 invoked by alias); 1 Dec 2003 21:32:06 -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 31653 invoked from network); 1 Dec 2003 21:32:04 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Dec 2003 21:32:04 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AQveE-00041v-DQ; Mon, 01 Dec 2003 16:32:02 -0500 Date: Mon, 01 Dec 2003 21:32:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses Message-ID: <20031201213202.GA5927@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <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> <3FCBB1DF.2050807@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FCBB1DF.2050807@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00030.txt.bz2 On Mon, Dec 01, 2003 at 04:25:51PM -0500, Andrew Cagney wrote: > >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. You're right. I was going to, so I'll do it below. I fail to see how it's related to the question above though. > Date: Mon, 24 Nov 2003 17:08:54 -0500 > From: Andrew Cagney > Subject: Re: [commit] Deprecate remaining STREQ uses > To: Daniel Jacobowitz > Cc: gdb-patches@sources.redhat.com > > > >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 :-( This is not the normal state of affairs. Normally bootstraps do work, and I only get mail when someone has newly broken the tree - and of the four times that's happened one of them was me, so I'd call it pretty good results. ARI runs a _lot_ faster than a GCC build/regression session. If you set the script to mail only on increases in problems, rather than on existing problems, you should be able to get a response pretty much at per-patch granularity. This is different from the way GCC uses their system, because GCC has an extremely different attitude towards the testsuite - failures are absolutely unacceptable. > 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). Check in the baseline status to the repository if you want to do that. Generate it during builds. Require people who check in patches which add ARI problems to also check in a patch bumping the failure totals, and it'll be obvious what's going on and where problems come from. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer