From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20801 invoked by alias); 22 Nov 2013 00:38:50 -0000 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 Received: (qmail 20790 invoked by uid 89); 22 Nov 2013 00:38:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-vb0-f45.google.com Received: from Unknown (HELO mail-vb0-f45.google.com) (209.85.212.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 22 Nov 2013 00:38:48 +0000 Received: by mail-vb0-f45.google.com with SMTP id p14so374196vbm.18 for ; Thu, 21 Nov 2013 16:38:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ju+QNpSM/WQN0dlfr3NEr+f8qh7uPz5Rf90B+RPwRBA=; b=DaNwZr/shMsSAmsonPqy8BApBi/fOu4UREWTmu/VNWlyb6FyYh1eyn6hASiAC+gw2X 7bnyiD2lL+pfAwgzTLFMv+DYGgZ/Qzn2HZ5aBcjtLbqJ7hkoX7ZKCJ6UqaR6gTuDO3o/ UL6XLVc0fKj9Zp6RbWomYo1Uis8g43tXIJmtuWD5uCnN5pjuM4DMM7gRHcRfd37PMF7E YcDLxWE5HhrSiBp21focFAVI7r3ZDs/8ea66vVqy/jn3gbf+XxgiBkxZEoAv5Ig/jy8D u04C1eHHIQGtXckMhxf3sc0+bVKq/j85O1oHR8C+W/1oPYffupsed227mPdqLF6snZUn XPzA== X-Gm-Message-State: ALoCoQkRgMZRWxEgBRJZc1M6inqzgb5Po2LvuD3Kn6N6H5pIhwINHWujqv4KYSAkw/h1TKPgzjHbSB4wkImfpvFha/lgV7X57LbvimuZIaY9j3h3ttH6Yhv6gc0suRWzS6JGPPBRy0abkHumx0pYShTqc4cwikfQj890V+l4VlhDfroxapbeV/3iPOdk5/HBPzsJw3r15huQTJ85JfcEDMUbVHj8EfKBJA== MIME-Version: 1.0 X-Received: by 10.58.254.200 with SMTP id ak8mr8548686ved.12.1385080720571; Thu, 21 Nov 2013 16:38:40 -0800 (PST) Received: by 10.52.163.52 with HTTP; Thu, 21 Nov 2013 16:38:40 -0800 (PST) In-Reply-To: <83bo1fg1x1.fsf@gnu.org> References: <1383458049-20893-1-git-send-email-yao@codesourcery.com> <1383458049-20893-5-git-send-email-yao@codesourcery.com> <83k3gpa0hf.fsf@gnu.org> <838uwmhgha.fsf@gnu.org> <83bo1fg1x1.fsf@gnu.org> Date: Fri, 22 Nov 2013 01:17:00 -0000 Message-ID: Subject: Re: [PATCH 04/10] Don't stress 'remote' in "Data Caching" in doc From: Doug Evans To: Eli Zaretskii Cc: Yao Qi , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00663.txt.bz2 On Tue, Nov 19, 2013 at 7:58 PM, Eli Zaretskii wrote: >> Date: Tue, 19 Nov 2013 18:16:46 -0800 >> From: Doug Evans >> Cc: Yao Qi , gdb-patches >> >> >> > Thanks. But may I ask in the future not to split the patches to >> >> > documentation that are related to the same series? When you split >> >> > them, it makes the review harder, as I see the documentation changes >> >> > piecemeal, rather than together. >> >> >> >> That may be hard to apply in general. >> > >> > I don't see why it would be. Can you elaborate? >> >> We actively ask people to do the opposite for code. > > I don't understand why, but I won't argue about that part. > >> So we would have one rule for code and the opposite rule for docs. > > Yes, but I see no problem here: the translation of code rules to docs > is problematic anyway. I think it would depend on the patch. In general I'd just apply something intuitive based on how I'm submitting the code changes. >> Sometimes a patch series will have several doc additions, that while >> collectively may appear as one doc patch, the submitter chose to break >> them up to keep them with their respective code parts. > > I'm asking that all documentation changes for a series appear as one > patch. I can add something to the patch submission guidelines that says that. >> I think it should be ok if someone did that ... we have a lot of rules >> to what is an acceptable patch already. > > I didn't suggest to add a new rule, I was just asking several > individuals to humor me. They can elect to ignore my request, if they > don't want to. > >> Can I suggest that we allow any GM to approve doc changes. >> We need all the review bandwidth we can get. > > If you think I'm slow in reviewing, let's talk about that. Rather, I didn't want to suggest an increased workload without also suggesting a way to share it.