It it true that patches are dropped or forgotten? Or is this a personal opinion?
Sometimes it just takes a bunch of prodding from multiple users to get a patch merged[4]. Sometimes even that isn't effective[5].
I didn't have to look hard to find these examples. I just scrolled through vim-dev looking for "patch" next to an unfamiliar name. This is a common problem with mailing lists: old things fade into oblivion whether or not they've been dealt with. Not so with GitHub's pull requests. PRs stick around until someone closes or merges them. That one difference makes it much harder for contributions to slip through the cracks.
1. https://groups.google.com/d/msg/vim_dev/iB2YYel67io/SBHYHpSM...
2. https://groups.google.com/d/msg/vim_dev/UTOY6V6UCkk/-0lqupnc...
3. https://groups.google.com/d/msg/vim_dev/0It1ZTos_QY/63Xc9NrT...
4. https://groups.google.com/d/msg/vim_dev/WeBBjkXE8H8/MRLPPMjV...
5. https://groups.google.com/d/msg/vim_dev/kG3Qaz8M9kw/YyZDzwkc...
2. Bram responds the next day. The submitter responds to Bram a week later...
3. Bram responds the next day.
4. Patch was merged after 4 months.
5. Bram responds same day after patch is added to mailing list.
Also it looks like a patch that is merged is put on the mailing list at the root and not as a reply to peoples messages.
So it is hard to tell how long someone submits something and when a patch is merged by looking at responses. You would have to find a patch someone submitted, then find Brams "Patch" messages to find when it was merged and compute time difference
2. Never merged, though a similar patch by the same person was merged a couple of weeks later. Try, try, again.
3. Never merged. Waiting on Bram.
4. Merged after 6 months, only because users constantly pestered. This patch was 12 lines, all straightforward.
5. Never merged. Bram said it was on his to-merge list in 2013.
All of these patches are pretty small. It shouldn't take long to reply with "Yes", "No", or "fix this". Yet the response is often one reply, followed by crickets. As 2 and 5 show, even the "yes" patches can fall through the cracks.
Bram's initial response can be quick, but it's often an ordeal to actually get a patch merged, even for trivial ones. This is likely due to a combination of Bram being a very busy person and mailing lists being terrible for this sort of thing.
So I don't think you can look for his response in the mailing list for a submission if it was merged or not. You have to look at the stream of merged patches.
What the hosting site could do is provide a way for users to build a customized image with selected contributed patches. This would allow the patches to be used without having to add more work to the primary developer.
The vim development model (patches + mailing list) has been pretty frustrating for some people. That's one of the reasons why NeoVim was forked.
Because pull requests can be ignored as well, although it is true that they're more visible than a mail in a mailing list archive.
GitHub lets you update patches easily (and see the updated patch), drop comments inline in a patch (very useful for code review), and tag patches (extremely useful for large projects).
Having to go through the extra hassle of a mailing list just to have the maintainer ignore them sucks.
Another benefit of GitHub is that users affected by an issue that has been patched but not merged can just fork the repo and merge the PR themselves and use that (I've done that in multiple cases). Mailing lists aren't as easy for this.
This is true, which I discovered while attempting to contribute to git itself. git's development uses this model, which probably means something, even if I can't figure it out.