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.