Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Implement -exec-jump
Date: Wed, 08 Apr 2009 07:08:00 -0000	[thread overview]
Message-ID: <200904081108.17248.vladimir@codesourcery.com> (raw)
In-Reply-To: <838wmb63h9.fsf@gnu.org>

On Wednesday 08 April 2009 10:53:22 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Wed, 8 Apr 2009 09:50:16 +0400
> > 
> > 
> > This patch, committed, implements the -exec-jump MI command.
> > (Documentation follows later)
> 
> Please don't commit patches without the docs to go with them.  Many
> people (and even distributions) use development snapshots or the CVS
> directly these days, and I would like to avoid the situation where
> they get features without documentation.  I think we all should want
> this.

Don't you think that if some person, or distribution, grabs random state
from CVS, he should be capable of judging what he gets? If he is 
incapable of such judgement, it is his problem.

> It is okay to _post_ a patch for review saying that the documentation
> patch will be _posted_ later, but actually _committing_ the code part
> is something very different.

Is this rule documented anywhere? And if it is, it is a very inconvenient 
rule. It is much easier for me to find two chunks of time for code and 
documentation separately, rather than finding large chunk of time to do
them both -- to the point where I might not be able to fix such small
issues at all. Do you think having a window of time where *development version*
has an undocumented feature that is primary targeted at *frontend developers*
is worse than not having that feature at all?

- Volodya


  reply	other threads:[~2009-04-08  7:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08  5:50 Vladimir Prus
2009-04-08  6:55 ` Eli Zaretskii
2009-04-08  7:08   ` Vladimir Prus [this message]
2009-04-08  7:22     ` Eli Zaretskii
2009-04-08  7:36       ` Vladimir Prus
2009-04-08  9:00         ` Eli Zaretskii
2009-04-08 16:26           ` Tom Tromey
2009-04-22 12:57           ` Vladimir Prus
2009-04-22 17:26             ` Eli Zaretskii
2009-04-08  9:16       ` André Pönitz
2009-04-08  9:29         ` Eli Zaretskii
2009-04-08 11:05           ` André Pönitz
2009-04-08 11:46             ` Eli Zaretskii
2009-04-08 21:51           ` Thiago Jung Bauermann
2009-04-08 21:57             ` Joel Brobecker
2009-04-10 16:50               ` Eli Zaretskii
2009-04-13 17:24                 ` Tom Tromey
2009-04-08 16:28         ` Tom Tromey
2009-04-08 22:03   ` Thiago Jung Bauermann
2009-04-22 12:09 ` Vladimir Prus
2009-04-22 17:16   ` Eli Zaretskii

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=200904081108.17248.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.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