From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30610 invoked by alias); 11 Oct 2004 22:00:49 -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 30593 invoked from network); 11 Oct 2004 22:00:47 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 11 Oct 2004 22:00:47 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i9BM0hc1003014; Tue, 12 Oct 2004 00:00:43 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i9BM0g2j001562; Tue, 12 Oct 2004 00:00:42 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i9BM0g8s001559; Tue, 12 Oct 2004 00:00:42 +0200 (CEST) Date: Tue, 12 Oct 2004 13:42:00 -0000 Message-Id: <200410112200.i9BM0g8s001559@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <01c4afd3$Blat.v2.2.2$08f43980@zahav.net.il> (eliz@gnu.org) 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> <416A23BA.2010603@gnu.org> <01c4afd3$Blat.v2.2.2$08f43980@zahav.net.il> X-SW-Source: 2004-10/txt/msg00292.txt.bz2 Date: Mon, 11 Oct 2004 22:42:57 +0200 From: "Eli Zaretskii" > 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. I can't speak for Andrew, but what personally surprised me is why all of I sudden you seem to be opposed to deprecating things. > 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. Only to the extent that we rob them of any further improvements for their platform. In my experience though we're not actually deliberately retiring features or platforms. Yes, we've been obsoleting stuff, but in almost all cases this has actually been a service to our users, since we save them the disappointment of discovering that GDB doesn't work at all on their platform after they built it. So I'm afraid you haven't actually answered Andrew's question :-(. > 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. Yes, but if there's an obvious place for documentation in the code it's probably better to but it there. For example, SPARC-specific stuff is better documented in sparc-tdep.c, core file related stuff probably belongs in corelow.c. > 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. Yup. Using deprecated_ is "explicitly deprecating" in my book. I understand your revulsion against the use of deprecated_ in the source code, and I did oppose to it in the past. However, it really has the benefits Andrew describes. I think that sometimes he goes to far. For eah deprecation there should be an alternative that's somewhat easy to implement. The DEPRECATED_TM_FILE is bad in this sense, since it is impossible to add a platform with SVR4-style shared libraries without using it, unless you refactor the shared library code. On the other hand, that's about the only thing that needs it, and DEPRECATED_TM_FILE serves the purpose of keeping people from using it liberally. I don't thing we should only deprecate things if all that's needed to undeprecate is a simple substitution. If maintainers do their job right they'll undeprecate the code they're maintaining as soon as possible. I think I've proven that this can be done. But I think the deprecator has at least an equal burden to undeprecate if he's able to do so. > 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. I think it is unavoidable if we want to keep GDB maintainable. In the end if no-one undeprecates a particular feauture or platform, we can conclude that no-one is actively maintaining that part of code. > - 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. There are quite a few platforms for which no active GDB developer has access to a usable system. Enforcing this would actually slow down development to a crawl. We really have to find a balance here. Mark