This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: MI: frozen variable objects
> 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