Re: [maint] The GDB maintenance process

[Jason Molenda <jason-swarelist at molenda dot com>]

On Wed, Feb 19, 2003 at 11:29:13AM -0500, Andrew Cagney wrote:
> 
> > Which reminds me.  We've got two GNATS databases set up for GDB: 'gdb'
> > and 'gdb-patches'.  Should we use the gdb-patches GNATS database to
> > separate them from bug reports?
> 
> No!!!!  That gdb-patches database should be deleted.  It's dead.
> 
> People already have to track:
> 
> - gdb@
> - gdb-patches@
> - gnats@
> 
> and that is to complicated for some.  At least, by having both patches 
> and bugs in a single database, we've a one stop-shop.  A better change 
> is to dump gdb-patches@


We've got two separate discussions here:  The social conventions
and procedures for how patches are discussed/applied, and the
infrastructure to support those things.

Using GNATS as the infrastructure to track patches is pathetic.
Using mailing lists to track patches is annoying.

For a minute, though, imagine a magical patch tracking database.
It would be at the core of the patch workflow, not something glommed
on to the side--anything that says "you send your note to gdb-patches
and then you enter it into the patch database" is missing the point.
It wouldn't be a bug database, it would be a patch database--it's
got to track updates to the patch, it's got to relate groups of
patches or patches dependant on other patches.  It'll track the
discussion about patches.  It could track various maintainer's
opinions on a patch (I like the -1/+0/+1 Apache scheme); it could
track when the patch is blocked on a particular person (submitter,
a maintainer), or maybe when the patch is waiting approval by any
one of several people.  It could even relate GNATS bugs and patches
that are attempting to fix those bugs, so when someone sees a bug
in the GNATS database that hasn't yet been fixed, they can click
over to the magical patch tracking database and see why that patch
isn't in yet.

All of these transactions are still visible on a gdb-patches list,
of course, but the mailing list is a read-only view on to what's
happening.  All additional comments or follow-ups are routed through
the magical patch tracking database, and reflected back out to the
gdb-patches list.


I've heard Sourceforge has such a tool.  JimI was telling me at
lunch how they track the tcl patches this way.  And there is a
separate mechanism that tcl and Python both use for larger-scope
proposals ("PEP" for Python, a "Python Enhancement Proposal").
For instance, here's a PEP to add a boolean type to Python:
	http://www.python.org/peps/pep-0285.html
And it has a link into the Patch Tracker sourceforget database 
for the patch to implement the proposal:
	http://python.org/sf/528022



Don't fall into the trap of saying "the only two ways patches can
be tracked are the gdb-patches mailing list or gnats".  Let's start
by imagining a patch database designed around our actual workflow,
one which would require a minor change in how we work and add a
tiny bit of extra patch-management overhead, and yield benefits of
not losing track of patches.  

If such a magical patch tracking database exists, would it be worth
changing our workflow to use it?  I know that patch submitters would
eagerly jump on such a system, but unless all the actual maintainers
think it's a net gain it's not going anywhere.

Once that's all decided - what we want, and if we'd even use it if
we had it - then there's the minor matter of making it exist. :-)
Maybe bugzilla or gnats can be adapted, maybe another program can
be found from the net or a free bit of code from Sourceforge's
PatchTracker can be appropriated, or maybe someone gets the joyus
chance to write it from scratch.  


Before we get bogged down in implementation details and discussions,
it's critical to discuss what such a system would do, and if we're
all willing to push gdb patch work through it.  If we can't dream
up such a system, then let's be happy with gdb-patches and URLs
for patch references.

J