From: Tom Tromey <tromey@redhat.com>
To: "Petr Hluzín" <petr.hluzin@gmail.com>
Cc: Anitha Boyapati <anitha.boyapati@gmail.com>, gdb@sourceware.org
Subject: Re: Testing Call frame information in .debug_frame section
Date: Tue, 15 Feb 2011 15:06:00 -0000 [thread overview]
Message-ID: <m3aahx9w2c.fsf@fleche.redhat.com> (raw)
In-Reply-To: <AANLkTi=iSXXjaqc0gDSFgEMPN3Fbc9aZ40Ff5KiUz0Rj@mail.gmail.com> ("Petr =?utf-8?Q?Hluz=C3=ADn=22's?= message of "Mon, 14 Feb 2011 23:43:29 +0100")
>>>>> "Petr" == Petr Hluzín <petr.hluzin@gmail.com> writes:
Petr> Are there more advantages? Are they pretty common? Is there an
Petr> automatized solution for them, yet?
>> One or two weeks after an initial submission, if there has been no
>> answer, just send a ping message as a follow-up to your patch. Then do
>> it every week.
Petr> This sounds quite mechanical, boring and common to a lot of people
Petr> (submitters). Great example of task suitable for machines. (Why do you
Petr> people choose such suffering?)
I am just describing the system as it actually exists, not really
defending it or anything. The way I look at it is that if you want to
get a patch in, you have to bear some of the burden.
gdb tried a patch tracker for a while but it didn't prove to be very
popular. Maybe most maintainers prefer working via email; but it is
hard to know for sure.
Recently some GCC developers started using Rietveld for patch tracking
and review:
http://gcc.gnu.org/ml/gcc/2011-01/msg00354.html
Doug suggested using it for GDB as well, but AFAIK nobody has set it up.
Maybe if you set it up, people would use it.
Tom
prev parent reply other threads:[~2011-02-15 15:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 13:04 Anitha Boyapati
2011-02-13 2:34 ` Petr Hluzín
2011-02-13 9:57 ` Anitha Boyapati
2011-02-13 15:11 ` Petr Hluzín
2011-02-15 17:41 ` Richard Henderson
2011-02-15 18:09 ` Anitha Boyapati
2011-02-15 18:48 ` Richard Henderson
2011-02-15 19:15 ` Anitha Boyapati
2011-02-15 19:03 ` [avr] gas support for cfi info Richard Henderson
2011-02-15 22:45 ` Petr Hluzín
2011-02-16 17:59 ` Richard Henderson
2011-02-16 22:49 ` Petr Hluzín
2011-02-17 16:12 ` Richard Henderson
2011-02-17 16:16 ` Tristan Gingold
2011-02-17 15:35 ` Anitha Boyapati
2011-02-17 16:05 ` Richard Henderson
2011-02-17 19:53 ` Richard Henderson
2011-02-22 16:18 ` Anitha Boyapati
2011-02-22 17:51 ` Richard Henderson
2011-02-15 18:18 ` Testing Call frame information in .debug_frame section Anitha Boyapati
2011-02-15 22:12 ` Petr Hluzín
2011-02-14 16:42 ` Tom Tromey
2011-02-14 22:43 ` Petr Hluzín
2011-02-15 15:06 ` Tom Tromey [this message]
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=m3aahx9w2c.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=anitha.boyapati@gmail.com \
--cc=gdb@sourceware.org \
--cc=petr.hluzin@gmail.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