The Linux Kernel guys seem to think otherwise.
- There are _lots_ of people hired full time to check no patches
get lost.
They're not lost, they are still in people's inboxes (unless they deleted them) and in the ML archive.
There is only one guy working fulltime taking care of all orphan Linux patches (well not fulltime really, even), FWIW.
- Patches still get lost or stay ignored pretty often.
If the author still cares, he can ping the patches after some certain period of time (don't be too impatient).
If really everyone is too busy or just no one cares, well, tough luck, that has nothing to do with what tools they use to run their business.
Of course it helps for a huge project like Linux that someone like MM regularly sweeps up all (small) patches that look good enough to him and/or whoever reviewed them on the list, to have those patches simmer in his experimental tree for a while.
At the other side of the spectrum, there are projects like GCC, where patches frequently are ignored or at least not reviewed for a month or more. Most such patches are huge invasive patches requiring in-depth specialistic knowledge of what that patch is touching.
Does that mean such patches should then just be "let in" without review?
Does it mean that we should keep a subset (namely, the new patch contents) of our development mailing list in a separate database (the tracker)? Would that really be harder to ignore (for the "bad guys") or easier to keep up with (for the "good guys")?
Segher