From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10998 invoked by alias); 22 Apr 2009 17:26:46 -0000 Received: (qmail 10981 invoked by uid 22791); 22 Apr 2009 17:26:44 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Apr 2009 17:26:37 +0000 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KII00F00I2FV100@i-mtaout7.012.net.il> for gdb-patches@sources.redhat.com; Wed, 22 Apr 2009 20:26:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.175.232]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KII00I3VJ3GOB80@i-mtaout7.012.net.il>; Wed, 22 Apr 2009 20:26:11 +0300 (IDT) Date: Wed, 22 Apr 2009 17:26:00 -0000 From: Eli Zaretskii Subject: Re: Implement -exec-jump In-reply-to: <200904221657.50303.vladimir@codesourcery.com> To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: <83bpqoha6k.fsf@gnu.org> References: <200904080950.16691.vladimir@codesourcery.com> <200904081136.09957.vladimir@codesourcery.com> <8363hf5xsc.fsf@gnu.org> <200904221657.50303.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/msg00597.txt.bz2 > From: Vladimir Prus > Date: Wed, 22 Apr 2009 16:57:49 +0400 > Cc: gdb-patches@sources.redhat.com > > > > 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. > > Sorry, I'm don't follow. It would take you a couple of minutes to document, > somewhere, whatever you've said in this thread, and this will make future > development process more smooth. Am I wrong? No, you are not wrong. However, my point was that we don't need (and in practice, cannot) rely on documented rules alone. > > 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. > > On tests, I similarly don't think that an overly strict approach will > not hurt. Sometimes, having tests checked in later is better approach > overall. I think the majority here thinks otherwise. > I somehow doubt that in my particular case, making me commit code and doc > patches always together will serve any purpose. It eases the burden, that's all. We are all busy people. > > Even just > > mentioning the command with minimal documentation and a FIXME for > > later would be good enough at this point. > > Do you have a mechanism to track FIXMEs in documentation, so that GDB 7.0 > is not released with FIXMEs in documentation? FIXME in a comment is not visible in the produced manual. What I was trying to say was that some minimal documentation is infinitely better than no documentation. > > 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. > > Frankly, I was never comfortable with the idea of posting "sketch" patches > for you to do the real work. It's an offer; if you are uncomfortable with it, you don't have to take it. But if it will help us get documentation in time, the effort is worthwhile for me. > You might want to note that the patch for -exec-jump docs was now posted, > and we're not even that close to branch point. Thank you.