Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Yao Qi <yao@codesourcery.com>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 04/10] Don't stress 'remote' in "Data Caching" in doc
Date: Wed, 20 Nov 2013 02:41:00 -0000	[thread overview]
Message-ID: <CADPb22TVRike0KudjGruk3DAXcZEk3dXeDx3Jnj7V58fj9LSkw@mail.gmail.com> (raw)
In-Reply-To: <838uwmhgha.fsf@gnu.org>

On Sun, Nov 17, 2013 at 1:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 17 Nov 2013 12:15:10 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: Yao Qi <yao@codesourcery.com>, gdb-patches <gdb-patches@sourceware.org>
>>
>> > 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.
So we would have one rule for code and the opposite rule for docs.
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 think it should be ok if someone did that ... we have a lot of rules
to what is an acceptable patch already.

>> For code we ask people to split such things out.
>> I can well imagine people applying the same logic to documentation.
>> I don't know that it necessarily applies here, but it could.
>
> Sorry, I don't understand: what logic?
>
> What I'm asking is not request me to review a 15-line change to
> documentation in 5 3-line pieces.

See my point above.

Can I suggest that we allow any GM to approve doc changes.
We need all the review bandwidth we can get.
And *even* if they make mistakes sometimes, *that's ok*'.  Even better.
Mistakes are great teachers (if handled appropriately). :-)


  reply	other threads:[~2013-11-20  2:16 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-03  5:57 [PATCH 00/10 V2] Cache code access for disassemble Yao Qi
2013-11-03  5:56 ` [PATCH 01/10] Remove last_cache Yao Qi
2013-11-17 19:52   ` Doug Evans
2013-11-03  5:56 ` [PATCH 09/10] set/show code-cache Yao Qi
2013-11-03 16:58   ` Eli Zaretskii
2013-11-18  8:23   ` Doug Evans
2013-11-03  5:56 ` [PATCH 08/10] Don't invalidate dcache when option stack-cache is changed Yao Qi
2013-11-17 22:02   ` Doug Evans
2013-11-18 14:12     ` Yao Qi
2013-11-18 15:51     ` Pedro Alves
2013-11-19  6:43       ` Yao Qi
2013-11-19 12:14     ` Pedro Alves
2013-11-19 14:06       ` Yao Qi
2013-11-03  5:56 ` [PATCH 03/10] Move target-dcache out of target.c Yao Qi
2013-11-17 20:15   ` Doug Evans
2013-11-18 15:53     ` Pedro Alves
2013-11-03  5:56 ` [PATCH 05/10] Invalidate or shrink dcache when setting is changed Yao Qi
2013-11-03 16:50   ` Eli Zaretskii
2013-11-17 20:55   ` Doug Evans
2013-11-18 14:31     ` Yao Qi
2013-11-18 15:59   ` Pedro Alves
2013-11-19  6:16     ` Yao Qi
2013-11-19 11:52       ` Pedro Alves
2013-11-19 13:12         ` Yao Qi
2013-11-03  5:56 ` [PATCH 07/10] Associate target_dcache to address_space Yao Qi
2013-11-03 16:48   ` Eli Zaretskii
2013-11-17 21:22   ` Doug Evans
2013-11-20  7:54     ` Yao Qi
2013-11-20 13:23       ` Yao Qi
2013-11-03  5:56 ` [PATCH 02/10] Don't update target_dcache if it is not initialized Yao Qi
2013-11-17 20:09   ` Doug Evans
2013-11-03  5:57 ` [PATCH 06/10] Add REGISTRY for struct address_space Yao Qi
2013-11-17 21:09   ` Doug Evans
2013-11-20  4:46     ` Yao Qi
2013-11-03  5:57 ` [PATCH 04/10] Don't stress 'remote' in "Data Caching" in doc Yao Qi
2013-11-03 16:55   ` Eli Zaretskii
2013-11-06  7:56     ` Yao Qi
2013-11-06 10:28       ` Eli Zaretskii
2013-11-17 20:34     ` Doug Evans
2013-11-17 21:44       ` Eli Zaretskii
2013-11-20  2:41         ` Doug Evans [this message]
2013-11-20  4:01           ` Eli Zaretskii
2013-11-22  1:17             ` Doug Evans
2013-11-20  3:58     ` Yao Qi
2013-11-11  9:38 ` [PATCH 00/10 V2] Cache code access for disassemble Yao Qi
2013-11-17 17:03   ` Yao Qi
2013-11-18  8:39 ` [PATCH 10/10] Use target_read_code in disassemble Yao Qi
2013-11-18 17:12   ` Doug Evans
2013-11-20  4:46 ` [PATCH 00/10 V2] Cache code access for disassemble Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADPb22TVRike0KudjGruk3DAXcZEk3dXeDx3Jnj7V58fj9LSkw@mail.gmail.com \
    --to=dje@google.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox