This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
Jason Molenda writes:
> On Wed, Feb 19, 2003 at 06:57:01PM -0500, Andrew Cagney wrote:
>
> > > Using GNATS as the infrastructure to track patches is pathetic.
> >
> > Not as pathetic as `cagney's mailbox sitting on a lapbrick with a
> > failing hard disk'.
>
> Well, yes. :-) I didn't mean "you, the fellow who has put patches
> into gnats, are a fool" -- I meant that the overhead over putting
> patches in gnats is too high compared with just sending them to
> gdb-patches. IMHO this is a method that will fail, which is why
> I dragged my feet when Elena originally requested the gdb-patches
> gnats database be set up. Ignoring the fact that gnats is a bug
It must have been my evil twin, because I don't remember asking for
this (I am in favor of something like it, though). To be honest, it
was a project that Jim Blandy started but wasn't finished. It was
abandoned because there were problems with including a patch
preserving spaces, or something like that.
> tracker--not a magical patch tracking database--as long as it isn't
> at the center of every developer/maintainer's patch workflow, it
> will be doomed to irrelevance.
>
> It's got to be easy, it's got to be relevant, and it's gotta be the
> way everything is done.
>
> > > Using mailing lists to track patches is annoying.
> >
> > Er, you can't track patches using a mailing list. A mailing list can be
> > used to submit/discuss patches. It can't be used to track their state.
> > that needs a database.
>
> I was speaking loosely - I meant the combination of the mailing
> list and the web archives of that mailing list. The mailing list
> web archives are a being used as the patch repository right
> now--people use URLs into the archives to refer to old patches,
> they use google or the htdig search engine to find old patches,
> and they grope around blindly to figure out what ever happened with
> a given patch.
>
> > Time to install aegis, ay?
>
> I've never looked at Aegis, so I can't say. First the gdb maintainers
> and developers need to decide what they want and will use, then
> make it exist; not look at what exists and settle for it. Maybe
> Aegis is exactly what we'd all love in a magical patch tracking
> database and we can use it as-is, but IMHO it's too early in that
> discussion to care one way or another.
>
>
> J