From: Andrew Cagney <ac131313@ges.redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: David Carlton <carlton@math.stanford.edu>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part
Date: Tue, 17 Sep 2002 12:49:00 -0000 [thread overview]
Message-ID: <3D87874F.8010603@ges.redhat.com> (raw)
In-Reply-To: <20020917193007.GA27789@nevyn.them.org>
> On Tue, Sep 17, 2002 at 02:44:56PM -0400, Andrew Cagney wrote:
>
>>
>
>> >Basically, at any point when you don't have a lot of temporary gunk. I
>> >confess, I'm of two minds about working on a branch for this sort of thing:
>> >I consider it very impractical for things which don't break up into
>> >pieces easily afterwards. GCC has been using an interesting approach,
>> >which I think we could adapt and extend here.
>
>>
>> GCC's approach relies on GCC's development cycle: break, fix, release.
>> You can only pull stuff in from those branches during the ``break''
>> phase. And during that phase, things, from what I've seen, really are
>> broken (I got stuck trying to commit a patch because I couldn't
>> build/test GCC for several weeks).
>>
>> I also, to be honest, think that GCC has bigger problems than GDB. With
>> GDB, the basic architecture is fine (if you look at the relationships
>> and ignore all the globals and messed up interfaces :-). GCC, on the
>> other hand, needs some of its fundamental data structures and algorithms
>> completly replaced.
>
>
> I think this is just as true of GDB.
Can you expand. GCC is getting an entirely new tree representation. I
don't see GDB getting anything that fundamental.
>> >How about a branch which require approval just like the mainline for
>> >large patches, although giving David a little more freedom to play
>> >around. Then, we'd allow large merges from the branch back to the
>> >trunk when they were ready and tested - larger patches than we'd
>> >normally accept all at once, because they'd already been approved.
>> >
>> >Andrew - thoughts? Does it have any interesting possibilities?
>
>>
>> Let me put it this way, I'm scared shitless of another HP jumbo patch.
>
>
> That's not the point. That's why I suggested a branch which does
> require approval, precisely so that we wouldn't get into that problem.
> But you don't seem to like that idea, so it's dead.
Me not liking an idea doesn't kill it. It is the symtab maintainers,
and not me that would do the review and hence, they and not me would
need to be ok with it.
Andrew
next prev parent reply other threads:[~2002-09-17 19:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-16 15:26 David Carlton
2002-09-16 15:30 ` David Carlton
2002-09-17 7:35 ` Daniel Jacobowitz
2002-09-17 9:03 ` Andrew Cagney
2002-09-17 10:43 ` David Carlton
2002-09-17 10:49 ` Daniel Jacobowitz
2002-09-17 11:34 ` David Carlton
2002-09-17 12:24 ` Andrew Cagney
2002-09-17 11:44 ` Andrew Cagney
2002-09-17 12:30 ` Daniel Jacobowitz
2002-09-17 12:49 ` Andrew Cagney [this message]
2002-09-17 13:32 ` Daniel Jacobowitz
2002-09-17 21:48 ` Daniel Berlin
2002-09-18 7:26 ` Andrew Cagney
2002-09-20 9:13 ` Jim Blandy
2002-09-17 12:59 ` Daniel Berlin
2002-09-17 13:13 ` Andrew Cagney
2002-09-17 9:29 ` Andrew Cagney
2002-09-17 11:04 ` David Carlton
2002-09-17 12:16 ` Andrew Cagney
2002-09-17 12:35 ` Daniel Jacobowitz
2002-09-17 12:46 ` David Carlton
2002-09-17 12:57 ` Andrew Cagney
2002-09-22 14:51 ` Jim Blandy
2002-09-17 12:54 ` Michael Snyder
2002-09-17 12:59 ` Daniel Berlin
2002-09-18 2:56 ` Richard Earnshaw
2002-09-18 14:07 ` Andrew Cagney
2002-09-19 3:14 ` Richard Earnshaw
2002-09-19 6:18 ` Elena Zannoni
2002-09-19 7:52 ` Richard Earnshaw
2002-09-19 7:51 ` Andrew Cagney
2002-09-22 14:41 ` Jim Blandy
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=3D87874F.8010603@ges.redhat.com \
--to=ac131313@ges.redhat.com \
--cc=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.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