4 ms·

It's true if you're not one of the regular contributors. Even small patches for things like syntax highlighting seem to languish[1][2]. For stuff that requires

• arcticfox 12y ago
  My goodness. I'm shocked anyone is motivated enough to even get stuff through that process.
  • iterati 12y ago
    Which is why neovim exists now.
    • sfk 12y ago
      Which practically no one actually uses.
      • sfk 12y ago
        I truly wonder what kind of idiot downvotes this. Pure propaganda.
      • sfk 12y ago
        And the new comment was downvoted within seconds. The stakes seem to be high in this thread...
        • DanBC 12y ago
          Complaints about downvotes will always get downvotes.
          • sfk 12y ago
            In realtime?
          • deleted 12y ago
            [deleted]
          • deleted 12y ago
            [deleted]
          • deleted 12y ago
            [deleted]
        • sfk 12y ago
          And the kind of hipsters who use neovim apparently have unlimited time for guarding threads and realtime downvoting.
• mempko 12y ago
  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. Looks like the response times are great! 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
  • ggreer 12y ago
    1. Never merged. No replies. 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.
    • mempko 12y ago
      I'm confused though. I don't ever see a response from Bram saying "merged this". Instead you see a constant stream of patches merged at the root of the mailing list. 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.
    • chrisbra80 12y ago
      1) Here the real problem is the maintainer of the syntax file who is hard to reach. I have contacted him several times but never got fa reply. No real problem of Vim. 2) merged February 25th. Not bad I would say (again a runtime file problem) 3) merged with 7.4.646 4) yes, sometimes it takes a while. 5) took long but has been merged with 7.4.652
• jhallenworld 12y ago
  I don't think Bram gets paid to maintain VIM, so you get what you get. Not to say that it did not take work to produce a patch, but it's also a lot of work to review and merge them. 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.
  • sigzero 12y ago
    He could broaden the team a bit with his vote overruling if needs be. That would certainly help.