From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9510 invoked by alias); 11 Oct 2004 06:10:37 -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 9496 invoked from network); 11 Oct 2004 06:10:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Oct 2004 06:10:35 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i9B6AT9v017613 for ; Mon, 11 Oct 2004 02:10:35 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9B6ALr01244; Mon, 11 Oct 2004 02:10:22 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 67B1628CD; Mon, 11 Oct 2004 02:10:02 -0400 (EDT) Message-ID: <416A23BA.2010603@gnu.org> Date: Mon, 11 Oct 2004 15:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20041009 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Discussion: Formalizing the deprecation process in GDB References: <20040927175539.GS974@gnat.com> <41637DBD.8030209@gnu.org> <01c4aba7$Blat.v2.2.2$141c3ea0@zahav.net.il> In-Reply-To: <01c4aba7$Blat.v2.2.2$141c3ea0@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00279.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. I can only guess or suspect. E-mail being a primative medium doesn't let us read between the lines and identify when there's an underlying issue. Here we've again made progress, we've gone from XM_FILE, to deprecation, to the agressive removal of code. What of the overall rate of change, and release cycles, ...? This is also why I've been stating principals and generalities - trying to figure out what the underlying issue is. "deprecation", since it is all internal, is hardest on the developers yet many are the ones expressing a certain appreciation. The "users" I interact with appreciate the more timely releases that give them faster acces to fixes, so I don't know what is "harsh" here. Can you explain? > 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. Now that cuts both ways, you've not convinced anyone either :-( >>> 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? [Sarcasm] Obviously, that's why I'm spending part of my time on internals documentation. > 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. The internals documentation should contain the process, or the overview. The code, the specifics. Unless of course I get around to doing to gdbarch.sh what I did for the observers (i.e., single source in observer.texi). >>> 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? You wrote: > More generally, AFAIR the "depreated_" stunt was invented mainly as an > aid to the maintainer(s): to make their job easier when they want to > know what stuff is candidate for deletion. It is a bit funny to see > this convenience trick sudenly being inflated with so much ideology. Besides being a slur, I find it really troubling that you've somehow become convinced of this. Back in '98 and '99, all significant technical discussion, and all technical decisions, were being made on cynus-internal mailing lists and in cygnus-internal meetings (It wasn't until '00 that things really improved) :-( Beyond the ChangeLogs there's little (other than hearsay) to go by. Looking in 4.18 (, I'd been adding comments and code marking various pieces of gdb as "deprecated. By 5.0 (2000-05) I was explicitly deprecating things. >>> 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. First, from the point of view of GDB's core. Everything is typically fixed. The problem is with the frindges - architecture / target / symtab / ... / specific code - that continues to use or rely on mechanisms long after the're no longer needed. Are you suggesting that I should be required to fix the fringes? We've debated that in the past and it was agreed (eventually even by some of the protractors) that we're better off having the person in a position to test the changes make the changes - the rationale is simple - we've consistently demonstrated that untested changes don't work. We just end up retaining totally broken but still buildable code. > 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. I'm lost. To my knowledge the "point where you stop chasing and start deprecating" is _not_ what this debate is about. Rather it is about what action should be taken when deprecating something: I believe your position is that: - something is identified as deprecated - it's recorded somewhere other than the code - we "fix" all [remining?] uses - the code is marked up while mine is: - something is identified as deprecated - the code is marked up - we "fix" all remaining uses The problem I have with your suggested change, and the reason I originally started explicitly deprecating was that I found it doesn't work - very early on I was recording things in just the documentation. The only effective way I've found of stopping the "breeding" of deprecated code is by having it explicitly identified in the code itself using markup. This clarification has had other benefits: it for instance has given us a more objective metric against which new contributions and updates can be measured - in the past it was very much a hit or miss (reviewer dependant) afair. I know it's also suffered from a few persistant grypes: - it makes merging hard During the period 2000 (when CVS went live) to mid 2003 (my role was changed) I was responsible for merging the public repository into "the cygnus tree". Given that I was performing weekly merges without problem I don't see what the problem is (and I was definitly eating my own dog food). - the bar keeps moving (up) As I've noted in another post, GDB's code base needs to advance and advancing it means continuous change. One consequence of that change is deprecation. We have to live with it. Andrew