Re: [commit] Deprecate remaining STREQ uses

Andrew Cagney
2003-12-03T03:47:49Z

>> >>> 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