Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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