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 20:52:00 -0000 [thread overview]
Message-ID: <17758.8216.142597.547417@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20061117151857.GB31319@nevyn.them.org>
> I think Vladimir's said everything I would have said in response to
> this.
He said (I had to read the archives as I'm not subscribed to gdb-patches):
...it seems to me that frontend authors
are much better testing branch before it's realeased than random CVS state,
If the CVS state is indeed random then that must reflect poorly on the review
process.
> Is your concern breaking your MI frontend in Emacs? If so,
> then you need to test - either routinely on HEAD, or if you have
> more limited time, then on release branches. That's why we keep
> release branches around for a few weeks and announce prereleases.
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. But I find something else
anomalous about this. Vladimir (on behalf of Codesourcery?) submits a patch
for MI which has 26 hunks which you're proposing to approve in three days,
just as a release is coming up. I have submitted many patches over the last
year which still not been reviewed/approved. Notably one patch for
-var-set-format which is just a one line change:
http://sourceware.org/ml/gdb-patches/2006-05/msg00348.html
resubmitted in August:
http://sourceware.org/ml/gdb/2006-08/msg00179.html
and one to fix an _existing_ bug (PR mi/2077):
http://sourceware.org/ml/gdb-patches/2006-10/msg00239.html
This does not seem impartial use of resources to review MI changes.
To balance that I must add that GDB development benefits immensely from
Codesourcery and I appreciate that you do a huge amount of work for no
personal gain.
> Whether the patch lands on GDB 6.6 or 6.7 doesn't make much difference
> to the risk. If there's no testing, it might be released broken; if
> there is testing, it won't be.
I have no formal testing process. I just use it and see if it breaks.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-11-17 20:52 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 [this message]
2006-11-17 21:05 ` Daniel Jacobowitz
2006-11-17 23:12 ` Nick Roberts
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.8216.142597.547417@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