This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [maint] The GDB maintenance process


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
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]