From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16703 invoked by alias); 11 Oct 2004 20:47:04 -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 16694 invoked from network); 11 Oct 2004 20:47:01 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 11 Oct 2004 20:47:01 -0000 Received: from zaretski (pns03-196-232.inter.net.il [80.230.196.232]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DUX44254 (AUTH halo1); Mon, 11 Oct 2004 22:46:33 +0200 (IST) Date: Tue, 12 Oct 2004 07:34:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <01c4afd3$Blat.v2.2.2$08f43980@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com In-reply-to: <416A23BA.2010603@gnu.org> (message from Andrew Cagney on Mon, 11 Oct 2004 02:10:02 -0400) Subject: Re: Discussion: Formalizing the deprecation process in GDB Reply-to: Eli Zaretskii References: <20040927175539.GS974@gnat.com> <41637DBD.8030209@gnu.org> <01c4aba7$Blat.v2.2.2$141c3ea0@zahav.net.il> <416A23BA.2010603@gnu.org> X-SW-Source: 2004-10/txt/msg00291.txt.bz2 > Date: Mon, 11 Oct 2004 02:10:02 -0400 > From: Andrew Cagney > Cc: gdb@sources.redhat.com > > 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. I don't know why you insist on trying to read between the lines and look for hidden issues. I try very hard to make the issues that bother me as explicit as I possibly can. > 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? When we retire some code or feature or platform, we hurt users of that code or feature or platform. > > 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 :-( I didn't start this thread. If we have nothing new to say to each other, perhaps we should just stop, since no one else seems to be interested. > > 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. And I know that, so I'm stunned to read words you've written that discourage documentation efforts. > The internals documentation should contain the process, or the overview. I think it can contain whatever we find useful to have there. There's nothing wrong with the idea that the internals docs will serve us a little, not just people outside the GDB development team. The documentation of the GDB release and branching processes are very good examples. > 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. My involvement with GDB goes back to 4.16 (although you probably won't find the traces in the logs). Perhaps my memory betrays me, but the massive use of deprecated_ is something that didn't start until 5.x. You seem to confirm that, although not in so many words. No slur was intended, of course; sorry if it sounded like that. > Are you suggesting that I should be required to fix the fringes? Not necessarily you. In every other GNU project that I was involved with, the person who wants to make a change is required to make sure nothing is broken by the change without an overall agreement that it is okay to break it. Breaking things just because no one is willing to make an effort to fix them is something I find to be very wrong. > - we've consistently demonstrated that untested changes don't work. Then the person who makes the changes needs to test them, or ask someone else to do that for them, if access to some specific platform is an issue. Yes, that _is_ harder than leaving things unmodified (i.e. broken), but that is the price we pay for the fun of being maintainers.