Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Doug Evans <xdje42@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Add support for embedding scripts in .debug_gdb_scripts.
Date: Wed, 21 Jan 2015 09:57:00 -0000	[thread overview]
Message-ID: <20150121095739.GB24515@adacore.com> (raw)
In-Reply-To: <CAP9bCMQM_cmsEwxNAjaSo+WNR_xOQ1Sqi6Z0VicUHFTyi47wZw@mail.gmail.com>

> > I just personally think this is too extreme a measure.  There are times
> > when absolute rules may be useful, but I don't think this is the case
> > here.
> 
> Eh? What we have here *is* an absolute rule:
> We used to be allowed to use phrases like NUL-terminated
> in documentation, now we are not.

True, but I just think it's not worth starting to write _rules_
down. If we start writing such rules down, then that means that
we must write down all other rules. Which seems OK in principle,
but when you get to that level of details, the list can become
so long as to be really hard to keep in mind. What I'm getting
at is that this is really a detail, and if we want to make
a rule of it, I'd create one more general that says "no outdated
expression" may be used.

> > Eli is our documentation maintainer,so let's continue trusting
> > his judgement. This discussion is not about black and white, and
> > as such, it's easy to disagree. But I don't think it's important
> > enough to spend more time on this. I know it can be fustrating
> > to make a change one does not believe in, but after a reasonable
> > attempt at discussing it, I'd go with his call.
> 
> I for one would liked to have seen the data to back up
> the claim that NUL-terminated is archaic.
> It's not that I don't trust someone's judgement, rather it's that that's
> the wrong way to impose the change.

FWIW, and this is only my personal opinion of course, since you are
in fact entitled to getting an explanation: Eli telling me, as our
Documentation Maintainer, "it reads better if you use [blah]", is
usually enough for me to follow his lead and make the change. I'd have
to disagree fairly strongly to argue further. Since (I think) Eli tried
to explain, is that the case, here? That you disagree fairly strongly
with Eli's assessment?

-- 
Joel


  reply	other threads:[~2015-01-21  9:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-15 17:32 Doug Evans
2015-01-15 18:11 ` Eli Zaretskii
2015-01-16 17:15   ` Doug Evans
2015-01-16 18:02     ` Eli Zaretskii
2015-01-17  1:16       ` Doug Evans
2015-01-17  8:16         ` Eli Zaretskii
2015-01-18  4:16           ` Doug Evans
2015-01-18 16:23             ` Eli Zaretskii
2015-01-18 20:48               ` Doug Evans
2015-01-19 14:49                 ` Joel Brobecker
2015-01-20 16:35                   ` Doug Evans
2015-01-21  9:57                     ` Joel Brobecker [this message]
2015-02-13 16:15                     ` Stan Shebs
2015-02-13 16:45                       ` Eli Zaretskii
2015-02-13 16:46                       ` Andreas Schwab
2015-02-13 18:05                     ` Pedro Alves
2015-02-15 11:53                       ` Corinna Vinschen
2015-01-19 16:05                 ` Eli Zaretskii
2015-01-31 23:31 ` Doug Evans

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=20150121095739.GB24515@adacore.com \
    --to=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=xdje42@gmail.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