Re: Discussion: Formalizing the deprecation process in GDB

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Wed, 06 Oct 2004 01:08:13 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb@sources.redhat.com, Andrew Cagney <cagney@redhat.com>

Andrew, thank you for an informative message.

Unfortunately, it doesn't help in making a progress in this
discussion, since all it does is reiterate your opinions that were
clear (at least to me) during the XM_FILE debate, or else explaining
principles and generalities that don't need to be explained.

I'm fully aware that you, and at least some of the other maintainers,
are eager to deprecate and remove code that you think is not
maintained quickly enough for your liking.  It is probably not news to
you that I don't like that eagerness; we had enough discussions in the
past along those lines, and I didn't make a secret out of my views.  I
think such tendencies are harsh on the users and on sysadmins (in
fact, they are harsh on everybody but GDB developers), and are not at
all justified by the added maintenance burden they are allegedly
supposed to magically remove.

So saying once again that you don't want to request patch contributors
(which is mostly yourself in the case of "deprecated_" stuff) to fix
the affected portions of the code as a perequisite for accepting the
patch, and that you don't want to maintain obsolete code, does not
change anything in what is already known as a serious disagreement.
If that is all we can say, let's just agree to disagree, and be done
with that.

If you do want to try to convince me, you (or someone else who thinks
like you) will have to do better than that.

> In theory deprecation should be initiated by the relevant maintaner - 
> arch, targ, symtab - but here reality is that I do it.  The process is 
> that they are posted one week and committed the next which gives plenty 
> of time for objection (and we've seen a few of them).

I'm not sure a week is enough for automatic commits of this kind, but
I'm not sure I'm willing to start another debate about that.

> We're programmers.  We speak through the code.  The internals document 
> has its place, but the bottom line is that the code and not the 
> internals document determines how GDB works.  Hence, that is what 
> programmers read.

I'm not sure what is it that you are saying here.  Should we abandon
gdbint.texinfo and instead rely on the code to explain itself, because
``we are programmers and thus code is the only thing we read''?  Maybe
I should stop trying so hard to review each documentation patch in a
matter of days, because the code already says all there is to tell?

I agree with the principle that we should draw a line somewhere
between the part of the documentation that should go into a manual and
the part that should stay in the code, so the argument is not over the
principle.  I hope you will agree that, in principle, _some_
information _can_ be put in a manual, because otherwise I don't
understand why you just pinged me to review your gdbint patches about
branching and versioning; why not have that as comments to version.in,
for example?

The issue at hand is not the principle, but rather my very specific
suggestion that the fact some code or method is deprecated could be
stated in the manual.  If you object to that specific suggestion,
please back up your opinion by specific arguments, not by reiterating
abstract principles to which we all agree.

> Real deprecation started with multi-arch in '98 (your first post was in 
> '99)

What does the date of my first post have to do with the issue at hand?
Isn't it possible that I've also read the archives, even beyond the
days I started to be an active GDB maintainer?

> Yes, it did make my job easier - I didn't have to chase after people 
> constantly reminding them that the're using deprecated methods and plead 
> with them not to.

Chasing after people vs deprecating every code portion you don't want
to try to fix are not the only two alternatives to solve the problem.
And even if those _are_ the only two alternatives, there's still a lot
of leeway as to the point where you stop chasing and start deprecating.
And the location of that point is _exactly_ what we disagree about.

Once again, to have a meaningful and potentially useful discussion,
specific arguments about practical criteria to reach the decision
between these two alternatives are needed, not reiteration of general
principles.