[maint] The GDB maintenance process

[Andrew Cagney]

> Sure.  But my portrayal isn't entirely inaccurate, either.  One example
> - inter-compilation-unit references in DWARF-2.  It's been posted at
> least twice, by different contributors.  When asked for changes,
> they've come back with changes.  It's still not supported, over a year
> later.

Yes, I think it is fair to say that we've recently dropped baton on that 
one :-(  JimB, what's the current status?

Anyway a mid-mortem is in order.

GDB has a serious problem with _old_ forks.  cf:

- hp fork
- apple fork
- act's fork
- caldera's fork

You'll note that, in each of these cases, they really are forks(1).  The 
relevent developers created their own repository and then went off into 
the wilderness only to mysteriously appear later with a jumbo patch.  I 
believe that decision for forking was largly driven by the desire to, 
due to short term commercial pressure, avoid doing the right thing.

Not unreasonably, the GDB developers asked that such jumbo patches be 
broken down into something more managable, more up-to-date, and (too 
often) `lint' free(2).

Also, not unreasonably, the GDB developers asked/questioned 
architectural decisions made on those branches.

Less realistic, perhaps, is an over expectation of how much a 
contributor can reasonably be asked.  Even ignoring those `comercial 
pressures', many contributors figure `take it or leave it'.  Maintainers 
need to be willing to not only spend time adding glamerous new features, 
but also when an important patch appears, pick it up and run with it(3).

One thing GCC(4) and GDB are now is encouraging exprementation on 
branches development to always occure on branches cut from the the 
relevant repository.  For GDB we've had both success stories but also 
disasters.  With that in mind, and looking at the GCC / GDB success 
stories, I'd suggest the following guidelines:

- branches shall post all commits
They don't need approval but can be commented on.

- branches shall to be focused
The interps branch started out too large with too many changes - look at 
the size of the final commit compared to that branch at its peak.  Much 
time was lost because the branch started with too much lint :-(

- branches shall track mainline.
This keeps the level of divergence under control.  It also keeps the 
pressure on developers to push cleanups and other stuff into the mainline.

Andrew

--

(1) I was discussing this with a GCC developer and they pointed out, for 
the reasons I note, that these are not branches.

(2) As in the stuff you find on your clothing (not the program).  Forks 
and branches, like navel's, are shockers for breeding lint - entropy 
that serves no useful purpose.

(4) Yes, as I mentioned, I discuss this with GCC developers to see what 
lessons can be learnt.

(3) Note that if I pick up a really old patch, I'll often review, tweak 
and commit it.  I figure that if a patch is more than a month old, it 
isn't realistic to be asking a contributor to make minor changes.