From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14768 invoked by alias); 10 Apr 2009 16:50:14 -0000 Received: (qmail 14755 invoked by uid 22791); 10 Apr 2009 16:50:10 -0000 X-SWARE-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,BAYES_00,BOTNET,J_CHICKENPOX_14,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Apr 2009 16:49:59 +0000 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KHW00B009BNWY00@i-mtaout1.012.net.il> for gdb-patches@sources.redhat.com; Fri, 10 Apr 2009 19:49:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.240.185]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KHW00D169F65370@i-mtaout1.012.net.il>; Fri, 10 Apr 2009 19:49:54 +0300 (IDT) Date: Fri, 10 Apr 2009 16:50:00 -0000 From: Eli Zaretskii Subject: Re: Implement -exec-jump In-reply-to: <20090408215744.GH7535@adacore.com> To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: <83k55s313g.fsf@gnu.org> References: <200904080950.16691.vladimir@codesourcery.com> <200904081108.17248.vladimir@codesourcery.com> <837i1v627o.fsf@gnu.org> <200904081116.41983.andre.poenitz@nokia.com> <833acj5wdi.fsf@gnu.org> <1239227439.8871.153.camel@localhost.localdomain> <20090408215744.GH7535@adacore.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00195.txt.bz2 > Date: Wed, 8 Apr 2009 14:57:44 -0700 > From: Joel Brobecker > Cc: Eli Zaretskii , Andr? P?nitz , gdb-patches@sources.redhat.com > > > Another way to do it would be to add pending items to a GDB release wiki > > page. Joel already uses this, in fact. So it's the easiest to implement. > > This mechanism is fine as far as I am concerned. I'd agree to that as a fallback, but I'd prefer to codify the current unwritten practice that code patches come with docs patches. The reason is that deferring documentation to when a release is impending would almost certainly mean that documentation in general and my free time in particular will be a roadblock on the way to a release. Also, some of the contributors might not be available then, which means we will have a dilemma: either release undocumented features or try to document them by someone who knows much less than the original author of the code. We had no problems until now with requesting docs (and a test case) together with the code. Why should we deviate from that now?