From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5347 invoked by alias); 28 Jun 2008 17:44:36 -0000 Received: (qmail 5336 invoked by uid 22791); 28 Jun 2008 17:44:35 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-dupuy.atl.sa.earthlink.net (HELO elasmtp-dupuy.atl.sa.earthlink.net) (209.86.89.62) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 28 Jun 2008 17:44:13 +0000 Received: from [68.108.140.244] (helo=macbook-2.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KCeT5-0003Wk-8I; Sat, 28 Jun 2008 13:44:11 -0400 Message-ID: <48667869.2090808@earthlink.net> Date: Sat, 28 Jun 2008 18:11:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vladimir Prus CC: gdb-patches@sources.redhat.com Subject: Re: [MI non-stop 0/11] Series overview References: <200806282033.28441.vladimir@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94020faa5e186aba25ab9d1e35d56501002350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: 2008-06/txt/msg00556.txt.bz2 Vladimir Prus wrote: > Eli Zaretskii wrote: > > >>> From: Vladimir Prus >>> Date: Sat, 28 Jun 2008 20:33:27 +0400 >>> >>> >>> All patches are ready to be committed, except the patch for enabling non-stop >>> with a single command -- that one needs discussion. >>> >> What about documenting the new features? >> > > Why do you think the MI non-stop spec and the thread behaviour spec were written? > As usual, and even more than usual due to huge amount of text, I'm not going to > mess with texinfo until I'm sure nobody has big objections about the behaviour. > I'm with Eli on this actually. I can sympathize with the desire not to waste time writing about code that won't go in, but if as you say, the patches are ready to be committed, and the basic design has already been approved, then it seems pretty likely that any documentation text will receive at most minor changes. The specs are good to have too, but they're not really a replacement for user documentation; in fact they should be fodder for the internals manual. A beneficial side effect of preparing doc text with the code is that it helps reviewers relate the code changes to intended observable behavior, whereas the spec might or might not be out of date, things having changed due to implementation issues or feedback on related work. Stan