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:36:00 -0000 [thread overview]
Message-ID: <200904081136.09957.vladimir@codesourcery.com> (raw)
In-Reply-To: <837i1v627o.fsf@gnu.org>
On Wednesday 08 April 2009 11:20:43 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Wed, 8 Apr 2009 11:08:16 +0400
> > Cc: gdb-patches@sources.redhat.com
> >
> > > 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?
>
> I don't know, and I didn't know every request needs a documented rule.
I believe that a development process that is based on a list of documented
rules or guidelines is in general more smooth, than one that relies on
ad-hoc requests.
> I at least thought it was an accepted truism that we as a team don't
> want undocumented features.
I though there's "in a published release" somewhere in the above statement.
> > 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?
>
> Yes, that's what I think.
I am 100% sure that both the person who filed the issue this patch
has fixed, and every single frontend developer, will disagree. And that's
why it would be best to have documented rules -- so that those rules can
be established once and we would not spend any more time discussing them.
(Even if such established rules increase an already-high overhead of GDB
hacking to the degree where I won't be able to fix such small bugs).
- Volodya
next prev parent reply other threads:[~2009-04-08 7:36 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
2009-04-08 7:22 ` Eli Zaretskii
2009-04-08 7:36 ` Vladimir Prus [this message]
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=200904081136.09957.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