From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16467 invoked by alias); 8 Apr 2009 21:51:12 -0000 Received: (qmail 16458 invoked by uid 22791); 8 Apr 2009 21:51:11 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e24smtp04.br.ibm.com (HELO e24smtp04.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Apr 2009 21:51:04 +0000 Received: from mailhub1.br.ibm.com (mailhub1.br.ibm.com [9.18.232.109]) by e24smtp04.br.ibm.com (8.13.1/8.13.1) with ESMTP id n38Ll5eH007635 for ; Wed, 8 Apr 2009 18:47:05 -0300 Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n38LpKMn1458556 for ; Wed, 8 Apr 2009 18:51:20 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n38LohVU011082 for ; Wed, 8 Apr 2009 18:50:51 -0300 Received: from [9.8.10.215] ([9.8.10.215]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n38LoeSY010989; Wed, 8 Apr 2009 18:50:41 -0300 Subject: Re: Implement -exec-jump From: Thiago Jung Bauermann To: Eli Zaretskii Cc: =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= , gdb-patches@sources.redhat.com In-Reply-To: <833acj5wdi.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> Content-Type: text/plain; charset=utf-8 Date: Wed, 08 Apr 2009 21:51:00 -0000 Message-Id: <1239227439.8871.153.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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/msg00160.txt.bz2 El mié, 08-04-2009 a las 12:26 +0300, Eli Zaretskii escribió: > > From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= > > Date: Wed, 8 Apr 2009 10:16:41 +0100 > > > > On Wednesday 08 April 2009 09:20:43 Eli Zaretskii wrote: > > > > From: Vladimir Prus > > > [...] > > > > Do you think having a window of time where *development version* > > > > has an undocumented feature that is primary targeted at *frontend developers* > > > > is worse than not having that feature at all? > > > > > > Yes, that's what I think. > > > > I disagree. > > Well, you are not responsible for the GDB documentation; I am. > > If we are going to allow committing undocumented code, I would ask to > install some procedures to make sure it gets documented eventually. I agree with Eli here. If we don't have a mechanism of ensuring that documentation will get written before a release, we should enforce that features always be committed with documentation. OTOH, if we agree that it's acceptable to have a time window where CVS HEAD has undocumented features (as long official releases are always documented), then I think we should discuss those mechanisms, since as Vladimir and André say, it does help GDB development moving forward. > For now, I don't have any practical suggestion for such procedures, Like Tromey said, one way to do it would be to enforce opening a documentation bug in bugzilla everytime an undocumented feature is committed, and marking those bugs as release-blocking. Then we should agree that a GDB release can only be made after all blocking bugs are closed (boy I *am* smart, am I not?). 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. -- []'s Thiago Jung Bauermann IBM Linux Technology Center