which patches to review

[Stan Shebs]

"David S. Miller" wrote:
> 
> Much of the commentary has been "the maintainers don't have the time",
> and my main point is that this is a self-fulfilling prophecy.  There
> are never going to be new up and coming GDB contributors, ie. the new
> manpower needed, if the status quo continues like this.

The system literally can't work if maintainers don't have the time
to review patches.  Maintainers either need to devote more time to
reviewing, or spend less time on each patch, or step back in favor
of someone who can do the job.

> Working on GCC/Binutils vs. GDB is like night and day, and I do not
> believe this has %100 to do with manpower issues, it's partly because
> of the approach taken by the maintainers to some extent.  This is a
> very large barrier to entry to get real work done on GDB, whereas for
> GCC/Binutils there really isn't.

One of the differences I notice with GCC is that there is less
agonizing over every detail of every patch.  When I put the basic
Darwin support into GCC, the files actually carried along some
crufty dead code inherited from old NeXT stuff, but since it only
affected Darwin, nobody worried about it (since then most of it
has been whacked).  There have been other patches that were brave
attempts, and looked good at first sight, but that didn't last a
week and had to be reverted.  No biggie, that's just a normal
part of the development process.

Another thing I notice with GCC is that while there is a wish
list for future development directions, patches are usually not
held hostage to that list.  It's OK for instance to wish that a
contributor would multi-arch an old macro instead of submitting
yet another use of it, but if the contributor doesn't want to do
that, take the patch anyway and worry about multi-arching later.

Stan