Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney <cagney@gnu.org>]

>> >>> 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 <cagney@gnu.org>
>> Subject: Re: [commit] Deprecate remaining STREQ uses
>> To: Daniel Jacobowitz <drow@mvista.com>
>> 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