From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: Vladimir Prus <vladimir@codesourcery.com>,
gdb-patches@sources.redhat.com
Subject: Re: MI: frozen variable objects
Date: Fri, 17 Nov 2006 23:12:00 -0000 [thread overview]
Message-ID: <17758.16602.791317.749944@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20061117210501.GA13104@nevyn.them.org>
> > If the changes go in after the release I generally have six months to spot
> > a bug, if they go in now I'll have roughly two weeks.
>
> I don't get the fuss. It's not an immensely destabilizing change or a
> huge new subsystem. Why should it be treated separately from any other
> patch posted in the last few months, in the later half of a release
> gap?
Since you are confident it DTRT, I guess there is no problem. More importantly
you have the authority, so just do it. Richard Stallman has no such qualms
(he calls it "exercising leadership").
Now Vladimir fetches values in one place, I have a small patch on top of that
which updates references properly, I think.
>...
> I appreciate that you fix things, especially those MI PRs. I will
> somehow get to them. But, good lord, I need more help from other
> maintainers!
>
> And more maintainers. All: Should Nick be an MI maintainer now?
I would just commit small patches (like -var-set-format) and try to provide
support for the larger ones (like Variable objects laziness).
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-11-17 23:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 21:53 Nick Roberts
2006-11-16 22:00 ` Daniel Jacobowitz
2006-11-16 23:07 ` Nick Roberts
2006-11-17 15:19 ` Daniel Jacobowitz
2006-11-17 20:52 ` Nick Roberts
2006-11-17 21:05 ` Daniel Jacobowitz
2006-11-17 23:12 ` Nick Roberts [this message]
2006-11-18 11:00 ` Eli Zaretskii
2006-11-17 6:25 ` Vladimir Prus
2006-11-17 18:14 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2006-11-18 6:59 Nick Roberts
2006-11-16 12:48 Vladimir Prus
2006-11-16 13:58 ` Greg Watson
2006-11-16 15:25 ` Frederic RISS
2006-11-16 15:55 ` Daniel Jacobowitz
2006-11-16 16:26 ` Frederic RISS
2006-11-16 16:34 ` Daniel Jacobowitz
2006-11-17 15:21 ` Greg Watson
2006-11-16 18:55 ` Vladimir Prus
2006-11-16 21:36 ` Frédéric Riss
2006-11-17 6:17 ` Vladimir Prus
2006-11-17 8:54 ` Frederic RISS
2006-11-16 18:47 ` Vladimir Prus
2006-11-17 15:09 ` Greg Watson
2006-11-17 15:15 ` Daniel Jacobowitz
2006-11-17 15:26 ` Greg Watson
2006-11-17 15:33 ` Daniel Jacobowitz
2006-11-17 15:41 ` Greg Watson
2006-11-17 15:45 ` Daniel Jacobowitz
2006-11-17 18:16 ` Daniel Jacobowitz
2006-11-17 15:35 ` Greg Watson
2006-11-17 15:27 ` Vladimir Prus
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=17758.16602.791317.749944@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@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