From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22378 invoked by alias); 3 Dec 2003 03:47:49 -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 22340 invoked from network); 3 Dec 2003 03:47:46 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 3 Dec 2003 03:47:46 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 034682B8F; Tue, 2 Dec 2003 22:47:37 -0500 (EST) Message-ID: <3FCD5CD9.9060500@gnu.org> Date: Wed, 03 Dec 2003 03: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: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses 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> <20031201213202.GA5927@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00064.txt.bz2 >> >>> 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. You proposed a change. I sketched out a rough set of criteria against which that alternative should be measured. >> 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. For GCC, perhaphs. In general, such systems do the testing up front ensuring that only fully qualified changes get committed. GCC is an atypical model here. > 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. After the commit is too late. As I note below, the contributor must be both aware of and be able to address the problem _before_ they submit their patch. That way they, and the maintainer, avoid bickering of things that really should not even need a discussion. >> 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. Any change needs to be a natural part of the development cycle: modify build test submit review commit The existing deprecate works because looking for deprecated is a relatively natural part of the patch review phase (and the issue is trivially addressed by contributors before they post their submition - if you look over the mailing lists you'll see a very high success rate and few problems with new contributors). Given that the ARI takes a measurable amount of time to run, it can't be addeded to the build process. However, as part of the testsuite might be more interesting: FAIL: number of occurances increases KPASS: number of occurances decreased PASS: something is zero KFAIL: number of occurances remained static Andrew