From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29004 invoked by alias); 13 Sep 2004 15:35:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28941 invoked from network); 13 Sep 2004 15:35:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 13 Sep 2004 15:35:24 -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 i8DFZJ2I021908 for ; Mon, 13 Sep 2004 11:35:19 -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 i8DFZHr22036; Mon, 13 Sep 2004 11:35:18 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 672D128D2; Mon, 13 Sep 2004 11:33:05 -0400 (EDT) Message-ID: <4145BDB1.6010601@gnu.org> Date: Mon, 13 Sep 2004 15:35:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Eli Zaretskii Cc: kettenis@gnu.org, brobecker@gnat.com, gdb-patches@sources.redhat.com Subject: Re: [patch] Deprecate XM_FILE and TM_FILE References: <413898FB.7080502@gnu.org> <01c49276$Blat.v2.2.2$c81daa00@zahav.net.il> <4139D06B.5060902@gnu.org> <01c4929c$Blat.v2.2.2$3333c200@zahav.net.il> <413A277E.3060700@gnu.org> <01c492ff$Blat.v2.2.2$4fec0480@zahav.net.il> <41407F45.2090401@gnu.org> <01c496a3$Blat.v2.2.2$8948c5e0@zahav.net.il> <4140BC4C.50003@gnu.org> <01c496b2$Blat.v2.2.2$22c509a0@zahav.net.il> <20040909212638.GI5843@gnat.com> <01c49718$Blat.v2.2.2$de0204a0@zahav.net.il> <200409101241.i8ACfUHq027340@juw15.nfra.nl> <01c49753$Blat.v2.2.2$b39e6b00@zahav.net.il> <41448FBF.50009@gnu.org> <01c498f7$Blat.v2.2.2$53c9e1a0@zahav.net.il> In-Reply-To: <01c498f7$Blat.v2.2.2$53c9e1a0@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00207.txt.bz2 >>> Date: Sun, 12 Sep 2004 14:04:47 -0400 >>> From: Andrew Cagney >>> Cc: Mark Kettenis , brobecker@gnat.com, >>> gdb-patches@sources.redhat.com >>> >>> I think this debate is over the point at which something can be deprecated. > > > It's about a point where something can be deprecated, and also about > the conditions that should be fulfilled for that. I think this is progress, this discussion is finally focusing in on specific concerns. >>> For GDB, as soon as we've got the new mechanism up and running - >>> confirming its ok - we're going to draw a line and deprecate the old >>> mechanisms. We're not going to require that every single detail of >>> every single dependant variant also be addressed. > > > I don't know about ``we'', but as far as I'm concerned, I cannot > approve a patch that deprecates XM_FILE as long as the 3 defines in > xm-go32.h are not set by an alternative non-deprecated mechanism. > > >>>> > We can easily do that (and actually do that) by rejecting patches that >>>> > use the old mechanism. >> >>> >>> We don't. > > > Yes, we do. You can find examples of that in the archives, including > messages by yourself. In the past, yes. Two problems were identifed: - there was no way for a contributor to predict ahead of time if/when ``old'' mechanisms would not be accepted - the process was comparable to a lottery :-( - patch reviewers were not tracking / rejecting code using ``old'' - I was the one running around asking people to not use old mechanisms (not a good move ;-) As a consequence we now explicitly deprecate: require a clear explicit weeks notice before someing is deprecated; and requiring that contributions decrease the deprecation count; and requiring that patch reviewers check for this. The ARI currently identifies rougly 70 ``old'' mechanisms as candidates for deprecation (possibly redundant, broken, unused, ...). I don't require any patch reviewer to track them, and I don't require any contributor to implement the work needed to formally deprecate them. >>> In the past, requests to not use old mechanisms have been [er] >>> declined > > > If such a request is declined, we can reject the patch. I don't see a > problem here. That is deprecation. For us to reject such a patch we must have clearly, explicitly and formally identify the mechanism as one that should not be used, and recorded the decision in a way that both the patch reviewer and contributor can quickly and efficiently access. Andrew