This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 04/10] Don't stress 'remote' in "Data Caching" in doc
- From: Doug Evans <dje at google dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 19 Nov 2013 18:16:46 -0800
- Subject: Re: [PATCH 04/10] Don't stress 'remote' in "Data Caching" in doc
- Authentication-results: sourceware.org; auth=none
- References: <1383458049-20893-1-git-send-email-yao at codesourcery dot com> <1383458049-20893-5-git-send-email-yao at codesourcery dot com> <83k3gpa0hf dot fsf at gnu dot org> <CADPb22ToZGdnbnPjOEbq6uvcBHjmjCAiU9FYskKMGLSpiPgJCA at mail dot gmail dot com> <838uwmhgha dot fsf at gnu dot org>
On Sun, Nov 17, 2013 at 1:21 PM, Eli Zaretskii <email@example.com> wrote:
>> Date: Sun, 17 Nov 2013 12:15:10 -0800
>> From: Doug Evans <firstname.lastname@example.org>
>> Cc: Yao Qi <email@example.com>, gdb-patches <firstname.lastname@example.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). :-)