This is the mail archive of the 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

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

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.



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

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