Re: [maint] The GDB maintenance process

[Elena Zannoni <ezannoni@redhat.com>]

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