From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12425 invoked by alias); 6 Oct 2004 13:21:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12383 invoked from network); 6 Oct 2004 13:21:28 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 6 Oct 2004 13:21:28 -0000 Received: from zaretski ([80.230.143.237]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CTL83696 (AUTH halo1); Wed, 6 Oct 2004 15:21:24 +0200 (IST) Date: Wed, 06 Oct 2004 13:39:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <01c4aba7$Blat.v2.2.2$141c3ea0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com In-reply-to: <41637DBD.8030209@gnu.org> (message from Andrew Cagney on Wed, 06 Oct 2004 01:08:13 -0400) Subject: Re: Discussion: Formalizing the deprecation process in GDB Reply-to: Eli Zaretskii References: <20040927175539.GS974@gnat.com> <41637DBD.8030209@gnu.org> X-SW-Source: 2004-10/txt/msg00125.txt.bz2 > Date: Wed, 06 Oct 2004 01:08:13 -0400 > From: Andrew Cagney > Cc: gdb@sources.redhat.com, Andrew Cagney 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.