This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [commit] Deprecate remaining STREQ uses
>>> 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