Re: [maint] The GDB maintenance process

Andrew Cagney
2003-02-19T14:50:09Z

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