From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21647 invoked by alias); 8 Apr 2009 09:00:09 -0000 Received: (qmail 21585 invoked by uid 22791); 8 Apr 2009 09:00:06 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BAYES_00,BOTNET,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; Wed, 08 Apr 2009 08:59:58 +0000 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KHR00A00Y81SN00@i-mtaout1.012.net.il> for gdb-patches@sources.redhat.com; Wed, 08 Apr 2009 11:58:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.163.15]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KHR00CG6Y96AO60@i-mtaout1.012.net.il>; Wed, 08 Apr 2009 11:58:18 +0300 (IDT) Date: Wed, 08 Apr 2009 09:00:00 -0000 From: Eli Zaretskii Subject: Re: Implement -exec-jump In-reply-to: <200904081136.09957.vladimir@codesourcery.com> To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: <8363hf5xsc.fsf@gnu.org> References: <200904080950.16691.vladimir@codesourcery.com> <200904081108.17248.vladimir@codesourcery.com> <837i1v627o.fsf@gnu.org> <200904081136.09957.vladimir@codesourcery.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/msg00143.txt.bz2 > From: Vladimir Prus > Date: Wed, 8 Apr 2009 11:36:09 +0400 > Cc: gdb-patches@sources.redhat.com > > On Wednesday 08 April 2009 11:20:43 Eli Zaretskii wrote: > > > From: Vladimir Prus > > > Date: Wed, 8 Apr 2009 11:08:16 +0400 > > > Cc: gdb-patches@sources.redhat.com > > > > > > > It is okay to _post_ a patch for review saying that the documentation > > > > patch will be _posted_ later, but actually _committing_ the code part > > > > is something very different. > > > > > > Is this rule documented anywhere? > > > > I don't know, and I didn't know every request needs a documented rule. > > I believe that a development process that is based on a list of documented > rules or guidelines is in general more smooth, than one that relies on > ad-hoc requests. That's fine with me, but I don't think it means that a request outside written rules should be automatically rejected just because it isn't documented. Our process is just barely documented, so building on that alone would make our work and cooperation much harder than it needs to be. A request to commit changes with docs is not different from a request to have a test case for each new feature. I think we should do both. > > I at least thought it was an accepted truism that we as a team don't > > want undocumented features. > > I though there's "in a published release" somewhere in the above statement. That's exactly the point: the release of GDB 7.0 is quite close. Since we don't have any means to track such issues, you are now effectively asking me to somehow make sure the appropriate documentation patch is committed before the release, preferably before the branch. I don't have enough free resources to do that, so chances are we will release GDB 7.0 with this feature undocumented. I'm talking from experience here, it's not just a theory. You will see in the logs that around April 2005 I made several massive changes to the manual, all of them to document commands and features that were left undocumented because of lax policies regarding documentation. I don't want us to be in such a bad situation ever again, and I don't have any means of preventing that except by asking that code and documentation always go together. > > > 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 am 100% sure that both the person who filed the issue this patch > has fixed, and every single frontend developer, will disagree. And that's > why it would be best to have documented rules -- so that those rules can > be established once and we would not spend any more time discussing them. Well, my rules are spelled out above. If no one objects, I volunteer to add them to MAINTAINERS. > (Even if such established rules increase an already-high overhead of GDB > hacking to the degree where I won't be able to fix such small bugs). Frankly, I don't understand why: the particular feature you added now does not need more than a few lines added to the manual. Even just mentioning the command with minimal documentation and a FIXME for later would be good enough at this point. In addition, I said many times in the past that if Texinfo and other technicalities are a burden, contributors can post the documentation in plain text in their own words, and I will convert them to valid Texinfo and reword as necessary. If that makes the burden easier, I'm here to make good on my promises. A bit of good will is all I need to make this happen.