gdb-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gdbheads] Let's resolve this quickly


From: Elena Zannoni
Subject: Re: [Gdbheads] Let's resolve this quickly
Date: Sun, 28 Mar 2004 12:05:03 -0500

Benjamin Kosnik writes:
 > 
 > >The usual pattern is "this patch broke X; fix it or I'll revert it"
 > >followed by either "no, no, I'll fix it!" or "you're right, that patch
 > >was broken, please do revert it."
 > 
 > This is my experience as well, as somebody who has been on both sides of
 > this issue.
 > 
 > :-)
 > 
 > Usually, the threat of reversion is all that is necessary to signify the
 > seriousness of the issue to both parties. (I've not had any experience
 > where this wasn't the case.)
 > 
 > > If gcc made it a critical goal that gcc always bootstrap on major
 > > architectures after every patch, then gcc development would measurably
 > > slow down.  It's OK that gcc is broken temporarily, as long as it gets
 > > fixed.
 > 
 > Yep. I think asking for patches to perfect, on all the hosts targets for
 > gcc or gdb, is really quite the impossible task. First of all, most GCC
 > developers don't have access to all the primary GCC build hosts to do
 > testing themselves. Certainly, clean builds on all primary hosts is
 > something to strive for, and it's always nice when this happens, but I
 > think planning for mistakes and allowing people the chance to make
 > things right is very necessary.
 > 

Nobody here is asking for patches to be perfect.  We do however have
procedures.  We have a script in gdb that tests some important builds,
and that patches should be tested against.  It's in the gdb directory.
Most changes are in target dependent areas or in common code, and the
script does guarantee that those are covered, at least as far as
building goes.  Sometimes if a patch cannot be tested aginst all the
platforms that it touches, the problem gets pushed back to the mailing
lists to look for volunteers to test the patch on the necessary
systems. It has worked pretty well so far.  If nobody can be found to
test the patch, we cross our fingers and let it in anyway.

I think the internal structure of gdb and gcc and their host/target
dependencies are different, so a comparison of requirements more in
detail would not be necessarily appropriate.  I hope I explained
enough of the process to give you a general feel.

 > Also, auto-testing of the build, which does a good job of pointing
 > fingers without personalizing the issue. Perhaps if gdb goes down the
 > route of opening up the patch process, it should put in place
 > auto-testers to verify the integrity of the gdb build on important
 > hosts.
 > 

We have a few volunteers that do this pretty regularly.

I don't believe that the patch process in gdb is 'closed'. I think it's
different from what you are used to.


 > -benjamin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]